Ví điện tử định danh eIDAS của Đức có cơ chế xác minh bảo mật thiết bị dựa trên tài khoản Apple·Google

 (bmi.usercontent.opencode.de)
1 điểm bởi GN⁺ 17 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • National EUDI Wallet của Đức duy trì tính toàn vẹn của xác thực danh tính điện tử thông qua cơ chế quản lý lỗ hổng bảo mật thiết bị di động (MDVM)
  • MDVM phát hiện lỗ hổng trong hệ điều hành và kho lưu trữ khóa phần cứng (HKS), và nếu rủi ro cao thì chặn việc sử dụng khóa xác thực
  • Trên Android, hệ thống dùng Google Play Integrity API và KeyAttestation; trên iOS, dùng Apple DeviceCheck·AppAttest để xác minh tính toàn vẹn của thiết bị
  • Do cấu trúc này, khi sử dụng chức năng định danh điện tử, quy trình xác minh dựa trên tài khoản Apple hoặc Google sẽ bắt buộc được kích hoạt
  • Toàn bộ hệ thống được thiết kế với mục tiêu ngăn chặn việc sao chép·lạm dụng khóa bởi kẻ tấn công và duy trì xác thực eID ở mức bảo đảm cao

Khái niệm quản lý lỗ hổng thiết bị di động (Mobile Device Vulnerability Management, MDVM)

  • MDVM là cơ chế trong kiến trúc National EUDI Wallet của Đức, có nhiệm vụ giám sát liên tục các lỗ hổng bảo mật trên thiết bị của người dùng và duy trì tính toàn vẹn của phương thức xác thực
  • Phát hiện các lỗ hổng đã biết trong HKS (kho lưu trữ khóa phần cứng) và hệ điều hành (OS), rồi chặn việc sử dụng khóa RWSCA/RWSCD nếu nguy cơ tấn công cao
  • Nhờ đó duy trì mức bảo đảm cao trong quá trình xác minh danh tính điện tử (eID) và ngăn chặn việc sao chép·lạm dụng khóa bởi kẻ tấn công
  • MDVM gồm bốn chức năng: xác minh trạng thái bảo mật của thiết bị và ứng dụng, nhận diện lớp thiết bị, kiểm tra lỗ hổng và quyết định sử dụng

Động cơ

  • Wallet Unit cung cấp phương thức xác thực gắn với nhiều phương tiện định danh khác nhau (như PID) thông qua cặp khóa công khai/riêng tư
  • Khi cấp PID, WB (Wallet Backend) xác nhận với PP (Provider Party) bằng OpenID4VCI Key Attestation rằng khóa đó được kiểm soát bởi một phương thức xác thực có khả năng chống chịu tấn công ở một mức nhất định
  • Theo ISO/IEC 18045 và quy định EU 2015/1502, việc xác minh danh tính điện tử ở mức bảo đảm cao đòi hỏi phương thức xác thực mạnh
  • Phương thức xác thực cung cấp hai bảo đảm
    1. Chống sao chép và chống giả mạo kho lưu trữ khóa
    2. Chống tấn công vào cơ chế xác thực người dùng
  • Bảo đảm thứ nhất có thể được triển khai bằng RWSCD dựa trên HSM, và đạt được độc lập với thiết bị người dùng
  • Bảo đảm thứ hai phụ thuộc vào bảo mật của thiết bị người dùng, gồm yếu tố sở hữu (dựa trên HKS) và yếu tố tri thức (mật khẩu, v.v.)
  • Với HKS hay OS của thiết bị di động, việc phân tích lỗ hổng và chứng nhận trước là điều không khả thi trong thực tế, và trước đây cũng đã có nhiều lỗ hổng được báo cáo
  • Vì vậy, hệ thống sử dụng cơ chế giám sát lỗ hổng trong khi vận hành (MDVM) để giảm khả năng bị tấn công, đồng thời chặn việc sử dụng khóa RWSCA/RWSCD trên các thiết bị có mức bảo mật không đủ

Các chức năng chính của MDVM

Chức năng Mô tả
Xác minh trạng thái bảo mật của thiết bị/ứng dụng Xác minh tính toàn vẹn và tính xác thực của thiết bị và ứng dụng Wallet, tận dụng các tính năng bảo mật của nền tảng và RASP (Runtime Application Self-Protection)
Nhận diện lớp thiết bị Nhận diện theo cách đã được xác minh về mẫu thiết bị, phiên bản OS, mức bản vá và thông tin HKS
Kiểm tra lỗ hổng theo lớp thiết bị Kiểm tra thông tin lỗ hổng mới nhất của OS và HKS
Quyết định sử dụng thiết bị/ứng dụng Dựa trên trạng thái bảo mật và thông tin lỗ hổng, hệ thống chặn xác nhận OpenID4VCI Key Attestation và chặn sử dụng khóa RWSCD trên thiết bị có mức bảo mật không đủ

Tín hiệu được thu thập

  • Các tín hiệu thu thập được được dùng cho ứng phó đe dọa, nhận diện lớp thiết bị và kiểm tra tính hợp lý (plausibility check)

  • Nguồn tín hiệu chính: KeyAttestation, PlayIntegrity, DeviceCheck, RASP, LPADB, DCVDB

  • Tổng quan

    Nguồn tín hiệu Đe dọa được xử lý Hiệp lực Ghi chú
    KeyAttestation Root, mở khóa bootloader, custom ROM, giả mạo ứng dụng, sao chép, giả lập, tấn công phát lại, v.v. LPADB, RASP Dùng làm đầu vào cho DCVDB
    PlayIntegrity Giả mạo ứng dụng, phát lại, root, custom ROM, phán định MDVM dựa trên backend của Google, công cụ đánh cắp thông tin xác thực, tấn công overlay, v.v. KeyAttestation, RASP Cần xác minh trạng thái bootloader
    iOS DeviceCheck Phát lại, giả mạo chứng chỉ, tấn công proxy, giả mạo ứng dụng RASP Thiếu bảo đảm mạnh về tính toàn vẹn thiết bị
    LPADB Che giấu root bằng khóa KeyAttestation công khai bị lộ KeyAttestation -
    DCVDB Phát hiện thiết bị không an toàn dựa trên lỗ hổng đã biết KeyAttestation, RASP Độ chính xác khi nhận diện lớp thiết bị là quan trọng
    RASP Phát hiện hooking ứng dụng, debugging, root, giả lập - Giám sát liên tục tính toàn vẹn trong thời gian chạy

Tín hiệu Android KeyAttestation

  • Nhận diện mẫu thiết bị, phiên bản OS, mức bản vá, trạng thái bootloader, v.v. thông qua thông tin xác thực phần cứng dựa trên HKS
  • Các mục tín hiệu chính
    • SecurityLevel: nhận diện loại HKS (TrustedEnvironment, StrongBox)
    • attestationIdModel/Product/Device: nhận diện mẫu thiết bị
    • osVersion / osPatchLevel: phiên bản OS và mức bản vá bảo mật
    • RootOfTrust: trạng thái bootloader và Verified Boot
    • AttestationApplicationId: tên gói ứng dụng, phiên bản, hash chứng chỉ ký
  • Danh sách thu hồi chứng chỉ Key-Attestation của Google được cập nhật chậm nên các khóa bị lộ công khai vẫn có thể tiếp tục được sử dụng
  • Trên một số thiết bị có thể thiếu một số trường nhận diện nhất định, vì vậy cần đánh giá cả ba trường

Tín hiệu Android PlayIntegrity Verdict

  • Xác minh tính toàn vẹn của ứng dụng và thiết bị thông qua Google Play Integrity API
  • Các mục tín hiệu chính
    • appRecognitionVerdict: ứng dụng có phải bản gốc hay không
    • deviceRecognitionVerdict: mức độ tin cậy của thiết bị (ví dụ: MEETS_STRONG_INTEGRITY)
    • appLicensingVerdict: có được cài đặt từ PlayStore hay không
    • playProtectVerdict: đánh giá rủi ro của Play Protect
  • MEETS_STRONG_INTEGRITY yêu cầu đã áp dụng bản vá bảo mật trong vòng 12 tháng gần đây
  • Để đảm bảo độ tin cậy của tín hiệu, cần xác minh chữ ký và giải mã
  • Cách đánh giá nội bộ của backend Google không được công khai

Android RASP

  • Giải pháp cụ thể vẫn chưa được chốt, hiện đang ở giai đoạn xác định chức năng cần thiết
  • Các chức năng phát hiện
    • App Hooking/Debugging: phát hiện thao tác động (Frida, Xposed, v.v.)
    • App Repackaging/Tampering: phát hiện sửa đổi ứng dụng và ký lại
    • UD Rooting/Emulation: phát hiện root, ảo hóa, môi trường tự động hóa
  • RASP cung cấp giám sát tính toàn vẹn trong thời gian chạy, đồng thời duy trì blocklist tách biệt với danh sách thu hồi của Google để ngăn các cuộc tấn công dựa trên khóa bị lộ

iOS DCDeviceCheck.AppAttest Attestation

  • Cấu trúc xác thực ứng dụng thông qua Secure Enclave và máy chủ Apple
  • Các tín hiệu chính
    • attestationObject: chứng minh khóa App Attest được tạo trong Secure Enclave
    • credentialId: định danh khóa App Attest
    • RP ID: App ID prefix + Bundle ID của ứng dụng
  • Chỉ báo rủi ro của Apple (receipt metric) có thể được dùng để phát hiện tấn công proxy, nhưng thiếu tiêu chí rõ ràng và có rủi ro lộ dữ liệu cá nhân do giao tiếp với máy chủ Apple
  • iOS không thể cung cấp thông tin dựa trên phần cứng về mẫu thiết bị, phiên bản OS/mức bản vá, mà chỉ có thể xác nhận qua truy vấn OS

iOS DCDeviceCheck.AppAttest Assertions

  • Cấu trúc xác minh dựa trên chữ ký được tạo bằng khóa App Attest
  • Các tín hiệu chính
    • assertionObject: bao gồm chữ ký cho challenge
    • keyId: định danh khóa App Attest
    • counter: số lần ký, phải tăng đơn điệu
  • Counter tăng đột ngột có thể cho thấy khả năng xảy ra tấn công proxy, còn giảm xuống có thể là dấu hiệu của tấn công phát lại

iOS RASP

  • Yêu cầu các chức năng phát hiện tương tự Android
    • App Hooking/Debugging, App Repackaging, App Tampering, UD Rooting, UD Emulation
  • App Sandbox, Code Signing và System Integrity Protection của Apple chỉ cung cấp bảo vệ tại thời điểm cài đặt, chứ không có chức năng phát hiện root·hooking·can thiệp lúc chạy
  • RASP bổ sung điểm này bằng cơ chế giám sát tính toàn vẹn trong thời gian chạy
  • Theo tài liệu của Apple, App Attest nêu rõ rằng “ứng dụng đã bị sửa đổi chạy trên thiết bị hợp lệ không thể tạo assertion hợp lệ”

Kết luận

  • MDVM đánh giá trạng thái bảo mật của thiết bị theo thời gian thực và chặn việc sử dụng khóa xác thực trong môi trường có khả năng bị tấn công cao, qua đó duy trì độ tin cậy của hệ thống xác thực danh tính điện tử
  • Trên cả Android và iOS, hệ thống kết hợp các tính năng bảo mật của nền tảng và lớp bảo vệ động dựa trên RASP để xây dựng cơ chế xác minh tính toàn vẹn thiết bị
  • Tồn tại sự phụ thuộc vào cơ chế xác minh backend của Google và Apple, và các phương thức đánh giá nội bộ không được công khai vẫn là một yếu tố bất định tiềm ẩn

Bài viết liên quan

1 bình luận

 
GN⁺ 17 ngày trước
Ý kiến trên Hacker News

  • Đặc tả eIDAS 2.0 không yêu cầu phần cứng cụ thể
    Nó chỉ là một cấu trúc để lưu trữ thông tin xác thực có thể kiểm chứng và các chứng thư được ký bằng mật mã
    Có vẻ như đội triển khai ở Đức đang lười biếng khi muốn né điều khoản “phải triển khai cơ chế để người dùng có thể xác minh tính xác thực của Wallet Unit”
    Có thể xem tài liệu liên quan tại EUDI Architecture and Reference Framework

    • Nhìn vào bản triển khai tham chiếu thì có vẻ những người bảo trì không muốn loại bỏ sự phụ thuộc vào Google
      Lý do không rõ ràng, nhưng nếu một việc cứ tiếp diễn vô cớ thì cuối cùng hẳn là có lý do
      Xem kho GitHub
    • Ở mục 5.4 về Attestation Rulebooks và Attestation Schemes có nêu rõ các quy tắc liên quan

  • Với tư cách là người triển khai phía Đức, theo quy định thực thi eIDAS thì phải sử dụng cơ chế attestation
    Điều này không thể hoạt động nếu không có hỗ trợ từ hệ điều hành
    Chúng tôi biết việc hiện chỉ giới hạn ở Google/Android không phải là tối ưu, và cũng đang có kế hoạch hỗ trợ các OS khác như GrapheneOS
    Chỉ là lúc này đây đơn thuần là vấn đề ưu tiên, chứ không phải không nhận thức được vấn đề

    • Phụ thuộc vào sản phẩm của hai công ty Mỹ không chỉ là “không hay” mà là một vấn đề nghiêm trọng
      Có rất nhiều trường hợp bị khóa tài khoản, và kiểu phụ thuộc này thà không có còn hơn
    • Xét về khả năng tiếp cận và tinh thần của eIDAS thì còn có yếu tố bất hợp pháp
      Rốt cuộc mọi công dân đều bị lệ thuộc vào điều khoản sử dụng của Google và Apple, và nếu tài khoản bị đình chỉ thì sẽ không thể truy cập dịch vụ eID
      Về mặt kỹ thuật vẫn có phương án thay thế, nên tìm ra lời giải như vậy là trách nhiệm của bạn
    • Với tư cách là công dân Đức, tôi muốn hỏi: tại sao vẫn tiếp tục khi biết rằng nó sẽ không hoạt động cho mọi công dân?
      Tôi đã chuyển từ Android dựa trên AOSP không có Google Play sang Ubuntu Touch, và sau này dự định chuyển tiếp sang postmarketOS
    • Mất quyền truy cập tài khoản Google là chuyện quá dễ. Khôi phục lại thì cũng không thể
      Xét những tình huống như vậy và rủi ro địa chính trị, không thể biện minh cho việc phụ thuộc vào một công ty cụ thể
      Cũng có một bài học trong giới phát triển rằng “giải pháp tạm thời là giải pháp vĩnh viễn nhất”
    • Những vấn đề vốn đã được giải quyết từ eIDAS 1 bằng Mobile-ID (dựa trên SIM) hay Smart-ID (quản lý khóa phía máy chủ),
      tại sao lại nhất quyết chuyển sang mô hình Wallet. Không có lý do gì phải phụ thuộc vào backend của hai công ty Mỹ

  • Cần phải xóa bỏ attestation hoàn toàn
    Ứng dụng không nên biết nó đang chạy trên thiết bị nào
    Người dùng tự bảo vệ thiết bị của mình là đủ, còn nhà phát triển chỉ cần đưa ra khuyến nghị
    Nó phải có thể chạy trên mọi môi trường như GrapheneOS, máy đã root, trình giả lập, lớp tương thích Linux, v.v.

    • Đúng vậy, đây là thiết bị của tôi nên tôi phải được dùng theo cách tôi muốn
      Việc ứng dụng tự động kiểm tra xem có được “chứng nhận” bởi Big Tech Mỹ hay không là không cần thiết
    • Bản thân khái niệm độ tin cậy của thiết bị là một ảo tưởng
      Nhìn vào lịch sử các máy console và điện thoại đã bị root thì không có bảo mật nào là hoàn hảo
      Sẽ hợp lý hơn nếu để việc gắn danh tính của người dùng với thiết bị thành một tùy chọn lựa chọn thêm
    • Tất nhiên bạn được tự do root hay chỉnh sửa, nhưng cũng phải chấp nhận hệ quả
      Nếu ứng dụng không thể tự xác minh tính toàn vẹn của nó thì một số chức năng sẽ không thể bảo đảm an toàn
      Cũng như giấy tờ tùy thân vật lý có giới hạn về hình dạng hay kích thước, một số ràng buộc nhất định là cần thiết
    • Tội tổ tông của điện toán hiện đại là các ‘thành phần bảo mật’ được thiết kế cho nhà sản xuất chứ không phải cho người dùng
      Việc không cấm các thành phần như vậy bằng luật từ thời NGSCB chính là khởi đầu của vấn đề

  • Nếu mất tài khoản Google/Apple thì sao?
    Nếu bị đưa vào diện trừng phạt như các thẩm phán của Tòa án Hình sự Quốc tế, bạn sẽ không thể truy cập eIDAS
    Việc xã hội châu Âu vẫn duy trì cấu trúc phụ thuộc vào các công ty Mỹ là một thực tế đầy mâu thuẫn

    • Ngay cả khi không phải người nổi tiếng, bạn vẫn có thể bị loại khỏi xã hội do tài khoản bị đình chỉ tự động
      Việc hai công ty nước ngoài nắm quyền giám sát và kiểm soát là rất nguy hiểm
    • “Nếu thủ đô của châu Âu nằm ở Washington” thì chuyện này có lẽ cũng là điều hiển nhiên
    • Vậy thì cũng sẽ không đi Waymo được nữa

  • Thật đáng sốc khi công chúng phản đối quá ít với những chính sách như thế này
    Với tư cách là phụ huynh, tôi hiểu việc cần kiểm soát hoạt động Internet của trẻ em,
    nhưng rốt cuộc nhà nước đang làm thay phần việc của cha mẹ và chúng ta đang đánh mất tự do và quyền riêng tư

    • Phần lớn mọi người chỉ hiểu một cách trừu tượng việc này ảnh hưởng đến cuộc sống của họ ra sao
      Nếu không phải mối đe dọa cụ thể kiểu như “chính phủ đọc tin nhắn WhatsApp của tôi” thì họ sẽ không phản ứng
    • Ở Đức, sự chú ý lại bị phân tán bởi những chủ đề tiêu hao như tranh cãi về giới hạn tốc độ
      Giới chính trị lợi dụng sự hỗn loạn này để che đi các vấn đề cốt lõi
    • Ngược lại, nhiều bậc cha mẹ còn ủng hộ việc hạn chế truy cập online
      Họ muốn con cái được bảo vệ khỏi sự khai thác sự chú ý của các tập đoàn lớn
      Ngoài đời thực đã có giới hạn độ tuổi thì online cũng không nhất thiết phải là ngoại lệ
    • Mọi người bị mắc kẹt trong bong bóng lọc của riêng mình nên thậm chí còn không nghe tới những vấn đề như thế này
      Nghĩ tới tương lai của dân chủ thì điều đó rất đáng lo ngại
    • EU trên thực tế đang vận hành như một nền tảng vận động hành lang
      Công dân cũng có thể vận động, nhưng việc đó tốn chi phí và cần phối hợp nên doanh nghiệp lớn chiếm ưu thế
      Gần đây cũng từng có vụ hạ tầng số của EU bị một nhóm hacker xâm nhập
      Bài liên quan

  • Việc yêu cầu phần cứng hay phần mềm cụ thể là phi lý
    Mọi công dân đều phải được dùng máy tính theo ý muốn của mình
    Xác thực chỉ cần mật khẩu hoặc cặp khóa là đủ, ai muốn thì có thể thêm TOTP hoặc khóa bảo mật
    Có cảm giác người ta đã quên mất rằng ngoài smartphone ra còn có những loại máy tính khác

    • EU nói sẽ làm hệ thống thanh toán độc lập với VISA và MasterCard, nhưng cuối cùng vẫn phụ thuộc vào app store
      Không có tài khoản Apple hoặc Google thì cũng không thể thanh toán bằng euro số
      Thật ngạc nhiên khi giới chính trị và ngân hàng không nhìn xa hơn được hai ba bước
    • Chính sách của EU không đi theo hướng “người dùng tự đánh giá rủi ro”,
      mà là nhà cung cấp dịch vụ phải bảo vệ người dùng
      Kết quả là việc giới hạn nền tảng hỗ trợ trở nên khó tránh khỏi
    • Nói rằng “phải chạy được trên mọi máy tính” là không thực tế
      Đâu có nghĩa về mặt pháp lý là nó phải chạy cả trên Apple II

  • Những người bị trừng phạt hoặc thuộc một số nhóm nhất định có thể không truy cập được Play Store,
    nên bản thân việc cài ứng dụng eIDAS cũng có thể là không thể

    • Nếu cần tài khoản thì đúng là vậy.
      Nhìn vào các vụ xóa tài khoản đối lập chính trị gần đây, với một số nhà chức trách thì điều đó thậm chí còn có thể là điều đáng mừng
    • Nhưng cốt lõi là bảo vệ khóa riêng
      Cần có thiết bị bảo mật như smart card, nên môi trường hoàn toàn mở là rủi ro
      Tôi hiểu việc muốn dùng “Android thay thế”, nhưng cũng cần biết đó là một môi trường không an toàn

  • Tôi tự hỏi EU sẽ lãng phí bao nhiêu ngân sách cho hệ thống kiểu này
    Tôi không hiểu rốt cuộc ai là người cần nó

  • Chỉ có Self Sovereign Identity (SSI) mới là giải pháp thực sự
    Danh tính của cá nhân không nên lệ thuộc vào bất kỳ cơ quan hay doanh nghiệp nào
    Danh tính đơn giản phải là ‘chính tôi’
    Điều cần thiết không phải Google ID hay Apple ID, mà là danh tính tự chủ

    • Nhưng “tôi đơn giản là tôi” không phải là xác minh danh tính ngoài đời thực
      Bạn đâu thể nói như vậy thay cho giấy tờ tùy thân ở quán bar
      Trong khế ước xã hội, xác minh danh tính mang tính chức năng vẫn là điều cần thiết
    • EU thực ra đã tạo ra ESSIF (European Self-Sovereign Identity Framework) từ năm 2019
      Hạ tầng đã tồn tại từ 7 năm trước, nên không thể chỉ nói rằng chính phủ là bất tài

  • Có vẻ như đã đến lúc xảy ra một “vụ cháy tòa nhà Quốc hội Đế chế phiên bản số”
    Tôi muốn hỏi đến bao giờ Đức mới thôi thói quen lặp lại lịch sử