- Apple và Google đang mở rộng việc sử dụng chứng thực dựa trên phần cứng, thúc đẩy nhiều dịch vụ hơn áp dụng và về lâu dài củng cố một cấu trúc loại trừ phần cứng và hệ điều hành không được phê duyệt khỏi cạnh tranh
- Play Integrity API của Google và App Attest API của Apple hoạt động tương tự nhau; Play Integrity yêu cầu chứng thực phần cứng ở mức
strong integrity và đang đi theo hướng từng bước yêu cầu điều này cả với device integrity
- Privacy Pass của Apple, Web Environment Integrity đã bị hủy của Google, và
reCAPTCHA Mobile Verification mang yêu cầu chứng thực lên web, khiến việc truy cập dịch vụ web có thể bị chặn nếu không có iOS hoặc thiết bị Android đã được chứng nhận
- Play Integrity API cấm GrapheneOS dù hệ điều hành này an toàn hơn các đối tượng được cho phép, đồng thời vẫn cho phép các thiết bị không có bản vá bảo mật suốt 10 năm, cho thấy mục tiêu cấp phép Google Mobile Services và loại trừ cạnh tranh nổi bật hơn lý do bảo mật
- Khi các dịch vụ chính phủ và ngân hàng ngày càng yêu cầu App Attest và Play Integrity, điều đó trên thực tế ép buộc phải dùng thiết bị Apple hoặc Android được Google chứng nhận, và có thể ảnh hưởng cả đến truy cập web từ Windows, Linux desktop và FreeBSD
Yêu cầu chứng thực đang mở rộng lên web
- Privacy Pass của Apple mang chứng thực phần cứng lên web để hỗ trợ vượt CAPTCHA trên phần cứng của hãng
- Khi đó, nhiều người xem điều này là vô hại vì cho rằng sẽ không có nhiều trang chặn người dùng không dùng phần cứng Apple
- Cả Apple và Google đều có khả năng đưa chứng thực phần cứng trên diện rộng hơn lên web
- Các dịch vụ ngân hàng và chính phủ ngày càng yêu cầu dùng ứng dụng di động, và có thể dùng chứng thực trong ứng dụng để ép buộc thiết bị và hệ điều hành do Apple hoặc Google phê duyệt
- Privacy Pass của Apple, Web Environment Integrity đã bị hủy của Google và reCAPTCHA Mobile Verification đang đưa xu hướng này lên web
- Các bài đưa tin hiện tại về reCAPTCHA Mobile Verification chưa xử lý đúng mức tác động và ý nghĩa của nó
- Cách làm này yêu cầu quét mã QR bằng điện thoại thông minh đã được chứng nhận để vượt reCAPTCHA trong một số tình huống nhất định, qua đó mang yêu cầu chứng thực phần cứng sang cả Windows, Linux desktop, OpenBSD và các môi trường khác
- Nhờ quyền kiểm soát reCAPTCHA, Google đang ở vị thế có thể khiến việc sử dụng một phần rất lớn của web đòi hỏi phải có iOS hoặc Android được chứng nhận
- Google định nghĩa các yêu cầu chứng nhận Android, bao gồm cả việc bắt buộc đóng gói kèm Google Chrome
- Hiện tại, reCAPTCHA Mobile Verification hoạt động với Google Play chạy trong sandbox trên GrapheneOS, nhưng nó tồn tại như một phương tiện để bắt đầu áp dụng điều này cả với các hệ thống không có chứng thực phần cứng
- Khi yêu cầu này được áp dụng, những người không có thiết bị iOS hoặc Android có thể bị chặn ngay cả khi không có điều kiện bổ sung nào
Play Integrity và việc loại trừ GrapheneOS
- Play Integrity API của Google cấm sử dụng GrapheneOS dù GrapheneOS an toàn hơn rất nhiều so với bất kỳ đối tượng nào được cho phép
- Play Integrity API cũng cấm các lựa chọn thay thế khác, và đây không chỉ là vấn đề riêng của các hệ điều hành dựa trên AOSP
- Ngay cả khi dùng hệ điều hành di động dựa trên FreeBSD cũng không tránh được vấn đề này, mà chỉ bị loại trừ nhiều hơn
- Play Integrity API vẫn cho phép cả những thiết bị không có bản vá bảo mật suốt 10 năm
- Mức
device integrity có thể bị vượt qua bằng giả mạo, nhưng nếu việc đó bắt đầu được dùng ở quy mô lớn, Google có thể phát hiện và chặn khá hiệu quả
- Để vượt qua mức
strong integrity, cần có khóa bị rò rỉ từ TEE hoặc SE
- Play Integrity API không đặc biệt an toàn và việc vượt qua tạm thời không hẳn là quá khó
- Đã có các framework giả mạo kiểm tra phần mềm, và cũng có thể mua các khóa bị rò rỉ để vượt qua chứng thực phần cứng
- Tuy vậy, việc vượt qua đang ngày càng khó hơn và thời hạn hiệu lực cũng ngày càng ngắn hơn
- Play Integrity không cung cấp chức năng bảo mật hữu ích, nhưng lại hoạt động rất hiệu quả trong việc loại trừ cạnh tranh
- Các dịch vụ yêu cầu Apple App Attest hoặc Google Play Integrity chủ yếu đang giúp Apple và Google duy trì thế song quyền trên thiết bị di động
- Play Integrity quan trọng hơn vì AOSP là mã nguồn mở
- GrapheneOS có thể được xác minh bằng chứng thực phần cứng, và lý do Google cấm GrapheneOS trong Play Integrity là vì GrapheneOS không cấp phép Google Mobile Services và không tuân theo các quy tắc phản cạnh tranh
- Những quy tắc đó đã từng bị xác định là bất hợp pháp ở một số nơi như Hàn Quốc
- Dịch vụ không nên cấm việc sử dụng phần cứng và hệ điều hành tùy ý
- Khi Google cho phép các thiết bị không có bản vá suốt 10 năm nhưng không cho phép một hệ điều hành an toàn hơn nhiều, rất khó để lập luận rằng đây là vì bảo mật
- Đây là cách áp đặt độc quyền thông qua việc cấp phép GMS
Dịch vụ chính phủ, ngân hàng và vai trò của quy định
- Chính phủ ngày càng bắt buộc dùng Apple App Attest và Google Play Integrity không chỉ cho dịch vụ của mình mà cả với dịch vụ thương mại
- EU đang dẫn dắt xu hướng áp các yêu cầu này vào thanh toán số, xác minh danh tính, xác minh độ tuổi và các lĩnh vực tương tự
- Nhiều ứng dụng của chính phủ trong EU đã có sẵn các yêu cầu như vậy
- Thay vì ngăn chặn các hành vi phản cạnh tranh nghiêm trọng của Apple và Google, chính phủ lại đang trực tiếp tham gia vào việc loại trừ cạnh tranh thông qua chính dịch vụ của mình
- Việc buộc mọi người phải dùng thiết bị Apple hoặc Android được Google chứng nhận không phải là bảo mật mà là hạn chế cạnh tranh
- Vấn đề đòi hỏi thiết bị iOS chưa chỉnh sửa hoặc Android có Google Mobile Services để truy cập dịch vụ ngân hàng, chính phủ hoặc vượt một số reCAPTCHA nhất định không chỉ là vấn đề của riêng GrapheneOS
- Nó cũng ảnh hưởng tương tự đến Windows, Linux desktop, FreeBSD và các môi trường khác
- Đây không phải vấn đề chỉ riêng Pixel, thiết bị Android hay hệ điều hành dựa trên AOSP, mà còn có thể ảnh hưởng tới truy cập web trên desktop
API chứng thực Android và Unified Attestation
- Android cung cấp một hệ thống chứng thực phần cứng tiêu chuẩn hỗ trợ hệ điều hành thay thế bằng cách cho phép dấu vân tay khóa khởi động đã xác minh
- Chứng thực phần cứng của Android chủ yếu sử dụng root of trust của Google và dịch vụ cấp phát khóa từ xa, nhưng bản thân API hỗ trợ root of trust thay thế
- Chứng thực phần cứng Android không nên bị dùng để loại trừ người dùng không sử dụng một phần cứng hay hệ điều hành cụ thể nào đó
- Tuy vậy, việc có thể cho phép root of trust và hệ điều hành tùy ý giúp dịch vụ có dư địa để chấp nhận nhiều đối tượng hơn
- Nếu Google thực sự nhằm mục đích bảo mật, họ có thể dùng chính hệ thống này để cho phép GrapheneOS trong Play Integrity
- Unified Attestation là một hệ thống phản cạnh tranh khác đang được nhiều công ty châu Âu thúc đẩy, và cũng sẽ loại trừ người dùng phần cứng và phần mềm tùy ý theo cách tương tự
- Unified Attestation không phải là giải pháp, mà còn tệ hơn nhiều so với API chứng thực phần cứng Android vốn cởi mở hơn rất nhiều
- Unified Attestation của Volla được xây dựng hoàn toàn trên API chứng thực phần cứng của Android
- Unified Attestation của Volla tồn tại để tạo ra cơ chế trong đó một cơ quan trung tâm và các dịch vụ kiểm soát điều gì được phép
2 bình luận
Tôi thích Google đến mức ước gì có khoảng năm cái luôn 🥰
Ý kiến trên Hacker News
EU Digital Identity Wallet (EUDI) yêu cầu chứng thực phần cứng của Google hoặc Apple, về thực chất là trói toàn bộ danh tính số của EU vào hai ông lớn Mỹ
Vừa nói về chủ quyền số mà lại đưa ra quyết định như vậy, có cảm giác như kiểu bảo vệ trẻ em được đặt cao hơn chủ quyền
https://gitlab.opencode.de/bmi/eudi-wallet/wallet-developmen...
Ngay từ đầu đã không hiểu vì sao họ lại đưa ra quyết định này
Rõ ràng đó là câu trả lời nhắm tới người dùng phổ thông không có kiến thức kỹ thuật
Có rất nhiều người nói rằng chủ quyền và thoát phụ thuộc vào Mỹ là quan trọng, vậy mà không thấy phản đối mạnh hơn, khiến tôi tự hỏi có phải chỉ là vì sự thiếu hiểu biết hay không
Điều này càng đúng hơn với các định danh chú trọng quyền riêng tư, nên chứng thực thiết bị trở nên quan trọng
Nếu không thể xác minh phần cứng có ngăn người dùng trích xuất khóa hay không, thì không thể đảm bảo khóa danh tính thực sự bị khóa trong thiết bị
Điều tệ nhất là cuối cùng những tội phạm đủ quyết tâm vẫn sẽ tìm ra cách trích xuất các khóa đó để dùng vào gian lận, và hệ quả là mã nguồn mở và điện toán mở bị phá hủy
Việc ai nên bị yêu cầu xuất trình giấy tờ tùy thân là một vấn đề khác, và trong phần lớn các tình huống chỉ diễn ra trực tuyến tôi cho rằng câu trả lời là “không”, nhưng giải pháp mà ngành tài chính đã tin cậy suốt hàng chục năm qua thì đã có sẵn
Ngay cả việc yêu cầu silicon và phần mềm được phê duyệt cũng chưa phải là vấn đề lớn nhất ở đây
Họ không dùng zero-knowledge proof hay blind signature
Vì vậy mỗi lần chứng minh bằng thiết bị, họ để lại một gói chứng minh có thể được dùng để gắn hành động đó với thiết bị
Họ đưa vào một cấu trúc lách luật, trong đó lấy ID dùng một lần từ máy chủ trung gian bằng ID thiết bị tĩnh để tạo cảm giác như có quan tâm đến quyền riêng tư, nhưng vì không biết các máy chủ trung gian đó làm gì nên cứ coi như tất cả đều bị ghi lại
Chỉ riêng đường dẫn chứng thực từ xa đã như vậy, còn đường dẫn DRM ID thì còn tệ hơn. Không có cách lách nào đáng kể, nên mọi máy chủ cấp phép đều có thể truy cập danh tính tĩnh được khắc trong silicon. Còn đường dẫn tài khoản Google thì khỏi phải nói
Thực ra đã từng có đề xuất dùng blind signature cho chứng thực từ xa, nhưng hiện tại không được dùng ở những nơi dễ thấy: <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation>
Có vài lý do khiến điều này xảy ra. Lý do quá rõ là họ muốn có khả năng xâm phạm quyền riêng tư khi cần, hoặc bị bắt buộc phải có khả năng đó
Một lý do khác là nếu không thể liên kết chứng minh với một thiết bị cụ thể, thì biện pháp giảm lạm dụng trên thực tế gần như chỉ còn giới hạn tốc độ, mà theo tiêu chuẩn của họ có thể là chưa đủ. Kẻ tấn công có thể dựng cả trang trại thiết bị, để mỗi thiết bị cung cấp chứng thực từ xa cho tác nhân xấu và kiếm tiền theo giờ
Tôi không hiểu làm sao có thể vừa giữ một dịch vụ ở trạng thái ẩn danh vừa giới hạn tốc độ
Nếu một dịch vụ có thể đếm xem hai yêu cầu có đến từ cùng một chủ thể hay không, thì hai dịch vụ cũng có thể giả làm cùng một dịch vụ để biết hai yêu cầu đó có đến từ cùng một chủ thể hay không và liên kết chúng với nhau
Những câu như “vấn đề không phải chứng thực phần cứng, mà là không dùng zero-knowledge proof” chính là đang bình thường hóa một hành vi mới
Không nên như vậy. Dù dùng zero-knowledge proof hay triển khai chứng thực phần cứng bằng công nghệ bảo mật hiện đại nhất, vấn đề vẫn là chứng thực phần cứng
Xác minh độ tuổi cũng vậy. Vấn đề không phải là xác minh độ tuổi dễ bị rò rỉ dữ liệu, mà bản thân vấn đề chính là xác minh độ tuổi
Từ lúc ứng dụng được công bố, tôi đã gần như chắc chắn kiến trúc của nó sẽ như vậy
Tôi cũng nhớ đã thấy thảo luận trên diễn đàn Graphene rằng DRM ID không chỉ được giữ nguyên mà còn giống nhau giữa các profile
Nếu đúng vậy thì điều gì sẽ là củ cà rốt hoặc cây gậy để thúc đẩy việc áp dụng
Đây là một thread cho thấy rất rõ vì sao công nghệ này đang trở thành vấn đề đối với bất kỳ thứ gì được gọi là “mở”
Lập luận kiểu “chúng ta chỉ cần tạo web riêng của mình” chỉ còn ổn cho đến khi mọi dịch vụ đều bị đặt sau một lớp web buộc người dùng phải sở hữu thiết bị di động được Google hoặc Apple phê duyệt
Google giờ đã chặn hoàn toàn việc đó với tôi
Tôi cứ bấm vào các ô vuông để chọn mục mà họ yêu cầu thì nó lặp vô tận, còn nếu thử dùng bản âm thanh thì bị chặn hẳn với lý do có hoạt động đáng ngờ
Nên dạo này tôi chỉ đi một mình, và năm nay cũng không gia hạn hội viên nữa
Lần gần nhất tôi có trải nghiệm tương tự là khi Facebook bắt đầu trở thành con đường duy nhất để tham gia một số sự kiện. Khi đó tôi cũng chỉ chấp nhận mình bị loại ra và dành thời gian cùng tiền bạc cho việc khác
Rất nhiều doanh nghiệp hay nhóm xã hội vốn đã chỉ có thể tiếp cận nếu đi qua Facebook, WhatsApp và những thứ tương tự
Nó thực sự giống một phản địa đàng cyberpunk kỳ quặc. Kiểu như bạn chỉ có thể gửi thư và bưu kiện cho những người đăng ký cùng một dịch vụ bưu chính tư nhân, hoặc chỉ có thể lái xe trên những con đường có cấp phép chéo với hãng xe của mình
Ngay cả nếu nó có giá trị bảo mật đi nữa, thì thiệt hại phụ là biến các hệ điều hành không phải của Google hay Apple thành công dân hạng hai, và đó mới là vấn đề cốt lõi
Có thể không thực tế với ngân hàng hay tương tác với chính phủ, nhưng với nhiều dịch vụ khác thì có lẽ vẫn làm được
Dù vậy, vẫn cần có người xây dựng thứ gì đó, và chi phí bị phân tán cho ít người hơn; lợi thế là không cần xây công nghệ quảng cáo nên độ phức tạp thấp hơn có thể vẫn không đủ bù lại
Tuy nhiên đây có thể là kiểu vấn đề của nguyên liệu tốt. Còn phần cứng thì sẽ khó hơn nhiều
Nghe có vẻ là câu hỏi ngớ ngẩn, nhưng tôi hỏi nghiêm túc đấy
Năm 1999, khi Intel định đưa số sê-ri mà phần mềm có thể đọc được vào CPU, đã có phản đối rất dữ dội và cuối cùng họ phải rút lại quyết định
Sau đó, những kẻ độc đoán luôn thúc đẩy “bảo mật” và điện toán đáng tin cậy vẫn tiếp tục đẩy mạnh TPM cùng các công nghệ liên quan, đồng thời góp phần vào sự trỗi dậy của các hệ sinh thái khép kín trên di động
Yêu cầu TPM của Windows 11 cũng là một bước nữa hướng tới mục tiêu đó. Tôi từng bị sốc vì lượng tuyên truyền ở đây và nhiều nơi khác cho rằng đó là điều tốt
Điều đó cho thấy rằng khi “bảo mật” được đưa ra làm cái cớ, rất nhiều người sẽ dễ dàng bị ép chấp nhận bất cứ điều gì. Mong là con số đó đang giảm đi
Cuộc chiến chống lại điện toán đa dụng vẫn đang tiếp diễn, và chúng ta phải tiếp tục chiến đấu
Stallman, như thường lệ, đã đúng. Đây là lúc đọc lại “Right to Read” của ông. Nếu chưa có thì một phim ngắn do AI tạo ra cũng có thể là ý tưởng hay
“Ai từ bỏ tự do để đổi lấy an toàn thì không xứng đáng có cả hai”
AI là một công cụ hoàn toàn tập trung và độc quyền
Như có thể thấy ngay trong thread này, thay vì động lực, sự phẫn nộ và phản ứng tự tổ chức trước những vấn đề như vậy, thứ nổi bật lại là sự tuyệt vọng kiểu “không ai quan tâm”, “chúng ta chẳng thể làm gì được”
Bỏ cuộc là cách chắc chắn nhất để thua
Các bình luận ở đây dường như đọc thành chuyện bản thân chứng thực là xấu, nhưng lập luận thật sự có vẻ gần hơn với việc phải có một con đường rõ ràng để các nhà cung cấp không phải Apple và Google cũng được bao gồm
Tiêu đề tạo cảm giác Apple và Google là kẻ xấu, làm chuyện này để củng cố độc quyền, còn đối thủ GrapheneOS thì đứng lên vì mọi người
Nhưng phản biện cuối cùng lại là họ cũng đáng lẽ phải được đưa vào, và việc họ bị từ chối bởi Play Integrity API của Google vì những lý do không rõ ràng rồi cho rằng các lý do đó là ác ý cho thấy họ cũng thừa nhận giá trị bảo mật của nó
Với dữ liệu danh tính quan trọng, việc chứng minh toàn bộ chuỗi chữ ký thực sự là cần thiết. Đó là cách duy nhất để tránh tình huống AI có thể dễ dàng tạo ra danh tính giả để lừa đảo
Bằng sáng chế và bản quyền vốn là những hình thức độc quyền nguyên thủy
Chừng nào phần mềm còn không phải mã nguồn mở, thì theo định nghĩa nó vẫn là độc quyền
Tôi ngạc nhiên vì không có nhiều người giàu trên HN tài trợ cho GrapheneOS hơn
Biểu đồ Venn giữa những người giàu và kỹ sư quan tâm đến vấn đề này có vẻ sẽ chồng lấp khá nhiều, mà Graphene, dù còn nhiều khuyết điểm, vẫn đang làm rất nhiều công việc nền tảng trong lĩnh vực này
Nền văn minh của chúng ta đang rất cần một cách để sửa đổi vi điện tử hiện đại sau khi sản xuất, ít nhất là ở các cửa hàng sửa chữa được trang bị tốt
Mức độ cấp thiết này đáng ra đã có từ hôm qua rồi
Hoặc là phải coi việc bán các thiết bị điện toán đa dụng với CPU hay SoC có bất kỳ loại bootloader ban đầu nào được nạp sẵn trong mask ROM là bất hợp pháp
Tức là sau khi reset, lệnh đầu tiên CPU thực thi phải đến từ một thiết bị lưu trữ nằm ngoài vật lý của gói CPU
Tham khảo: https://pluralistic.net/2026/01/01/39c3/
Ngay cả SoC tương đối đơn giản cũng làm rất nhiều việc trong boot ROM không được tài liệu hóa để hỗ trợ quá trình reset trước khi tới được reset vector ở mức kiến trúc
Cũng có giá trị lớn trong việc đặt các routine DFU mức thấp vào boot ROM không thể bị xóa nhầm
Silicon của SoC có thể được sửa đổi để ghi lại mọi lệnh đã thực thi từ lúc cấp nguồn cho đến lệnh bàn giao secure boot
Nếu thêm các lệnh phụ trợ như truy vấn trạng thái, có bị tràn hay không, tạo chữ ký, thì hệ điều hành có thể tự tạo chứng thực đồng thời ngầm báo cáo mọi can thiệp trước khi boot
Chỉ cần coi việc nhúng dữ liệu khóa được hardcode vào bootloader và dùng khóa đó để xác minh mã được nạp là bất hợp pháp là đủ
Điều gây ngạc nhiên là chúng ta đang để cho Google và Apple quyết định ai được hay không được truy cập vào những dịch vụ hoàn toàn không liên quan đến họ
Hãy tưởng tượng bị chặn khỏi dịch vụ của Google vì quan điểm chống Google, rồi vì thế mà cũng không thể đăng nhập vào tài khoản ngân hàng của mình
Thật sự cần phải chia tách Alphabet
Với một chủ đề nghiêm trọng như thế này, có lẽ một bài viết thực tế, có lập luận rõ ràng gói gọn trong một trang sẽ tốt hơn nhiều so với một thread khó đọc như vậy