Việc triển khai eIDAS của Đức sẽ yêu cầu tài khoản Apple/Google hoạt động

Động lực¶

Wallet Unit cung cấp các phương tiện xác thực có thể liên kết với nhiều phương tiện nhận dạng, chẳng hạn như PID, thông qua một cặp khóa công khai/riêng tư, xem mật mã.

Khi cấp PID, WB xác nhận với PP (thông qua OpenID4VCI Key Attestation) rằng các khóa mà PID sẽ được liên kết đang được kiểm soát bởi một phương tiện xác thực(../05-cryptography.md) đáp ứng các yêu cầu bảo mật nhất định liên quan đến khả năng chống lại kẻ tấn công có sức tấn công nhất định (xem ISO/IEC 18045).

Hơn nữa, trong bối cảnh thực hiện nhận dạng điện tử ở mức độ đảm bảo cao, chẳng hạn như PID, yêu cầu xác thực người dùng ví phải tuân thủ các yêu cầu về đặc điểm và thiết kế của phương tiện nhận dạng điện tử ở mức độ đảm bảo cao, như được nêu trong Quy định thực thi (EU) 2015/1502 (xem CIR 2024/2979 Điều 5 1. b/g).

Do đó, phương tiện xác thực cung cấp hai đảm bảo quan trọng:

1. Phương tiện xác thực bảo vệ chống lại các cuộc tấn công sao chép và giả mạo vào kho khóa bởi những kẻ tấn công có khả năng tấn công cao. Do đó, PP có thể chắc chắn rằng các chứng chỉ đã cấp được liên kết với các khóa của phương tiện xác thực không thể bị kẻ tấn công có khả năng tấn công cao sao chép và do đó phương tiện nhận dạng tự nó không thể bị sao chép toàn bộ (xem CIR 2015/1502 Phụ lục 2.2.1).

2. Phương tiện xác thực bảo vệ chống lại các cuộc tấn công vào cơ chế xác thực của người dùng bởi những kẻ tấn công có khả năng tấn công cao. Do đó, PP có thể chắc chắn rằng các chứng chỉ đã cấp được liên kết với các khóa của phương tiện xác thực không thể bị kẻ tấn công có khả năng tấn công cao lạm dụng, ví dụ: để trình bày một lần chứng chỉ (xem CIR 2015/1502 Phụ lục 2.3.1).

Đảm bảo đầu tiên có thể đạt được bằng cách tạo và xử lý các khóa liên quan trong RWSCD được triển khai dưới dạng HSM đã được đánh giá và chứng nhận phù hợp. Do đó, đảm bảo này có thể đạt được độc lập với thiết bị người dùng.

Đảm bảo thứ hai liên quan đến cơ chế xác thực của người dùng đối với bên liên quan khi trình bày chứng chỉ. Điều này bao gồm xác thực hai yếu tố của người dùng đối với RWSCA. Bảo mật của cơ chế xác thực người dùng và các yếu tố xác thực phụ thuộc vào bảo mật của thiết bị người dùng. Giải pháp bao gồm một yếu tố sở hữu được bảo vệ bởi HKS của thiết bị di động và một yếu tố kiến thức được nhập qua thiết bị di động.

Bảo mật của yếu tố sở hữu phụ thuộc vào sự tồn tại của các lỗ hổng có thể bị khai thác trong HKS của thiết bị di động cho phép trích xuất hoặc lạm dụng khóa.

Bảo mật của yếu tố kiến thức phụ thuộc vào sự tồn tại của các lỗ hổng có thể bị khai thác trong phiên bản ví và/hoặc hệ điều hành của thiết bị di động.

Trên thực tế, không có phân tích lỗ hổng và chứng nhận HKS hoặc HĐH trước đó liên quan đến khả năng chống lại sức tấn công cụ thể, điều này sẽ làm giảm đáng kể khả năng tồn tại các lỗ hổng liên quan, đối với các thiết bị di động. Thay vào đó, có thể nhận thấy rằng trong quá khứ đã có những lỗ hổng liên quan được biết đến đối với các thiết bị di động.

Vì lý do này, giải pháp cung cấp việc giám sát các lỗ hổng đã xác định đối với HKS và hệ điều hành của thiết bị người dùng thông qua quản lý lỗ hổng thiết bị di động (MDVM) trong quá trình hoạt động để giảm khả năng khai thác các lỗ hổng liên quan hiện có. Điều này đạt được bằng cách đảm bảo rằng nếu có các lỗ hổng đã biết đối với thiết bị người dùng có thể ảnh hưởng đến cơ chế xác thực của người dùng đối với RWSCA với sức tấn công 'cao' hoặc thấp hơn, việc sử dụng các khóa được bảo vệ bởi RWSCA/RWSCD sẽ bị ngăn chặn. Do đó, việc xác nhận của WB đối với PP vẫn hợp lệ.

Để đạt được mục tiêu này, MDVM cung cấp các chức năng sau:

Chức năng	Mô tả
Xác minh tình trạng bảo mật thiết bị/ứng dụng	Cung cấp thông tin đã xác minh về tính toàn vẹn và xác thực của thiết bị, cũng như tính toàn vẹn và xác thực của ứng dụng ví cho một thiết bị người dùng/phiên bản ví cụ thể. Để đạt được điều này, các chức năng bảo mật từ nền tảng của thiết bị người dùng được sử dụng, cũng như các giải pháp độc lập với nền tảng như RASP (Runtime Application Self-Protection).
Xác định lớp thiết bị	Cung cấp thông tin đã xác minh về mẫu thiết bị, hệ điều hành bao gồm phiên bản và cấp độ vá lỗi và HKS. Điều này có thể đạt được với thông tin đã xác minh từ chứng nhận nền tảng và chứng nhận RASP.
Xác minh lỗ hổng cho các lớp thiết bị	Cung cấp thông tin cập nhật về các lỗ hổng liên quan của hệ điều hành thiết bị và HKS của một lớp thiết bị chuyên dụng.
Quyết định sử dụng thiết bị/ứng dụng	Dựa trên thông tin bảo mật và lỗ hổng của thiết bị/ứng dụng, (1) ngăn chặn việc xác nhận với PP thông qua OpenID4VCI Key Attestation nếu thiết bị/phiên bản ví không đủ bảo mật, (2) ngăn chặn việc sử dụng khóa RWSCD bằng cách xác thực người dùng với thiết bị/phiên bản ví không đủ bảo mật.

Các thành phần và vai trò để cung cấp các chức năng này được giới thiệu trong chương phân rã của kiến trúc.

Các Tín hiệu Thu thập được¶

Chương này cung cấp tổng quan về các tín hiệu được thu thập và ánh xạ của chúng tới các mối đe dọa liên quan. Nó cũng mô tả các cách sử dụng bổ sung của các tín hiệu này để kiểm tra tính hợp lý và xác định lớp thiết bị được sử dụng để truy vấn cơ sở dữ liệu MDVM.

Tổng quan¶

Nguồn tín hiệu	Mối đe dọa	Sự cộng hưởng	Ghi chú
KeyAttestation	rooting qua bộ nạp khởi động đã mở khóa, hình ảnh hệ thống không xác định (ví dụ: ROM tùy chỉnh), mất gốc tin cậy (ví dụ: chuỗi khởi động bị thao túng), đóng gói & giả mạo & giả mạo & hạ cấp ứng dụng, sao chép ứng dụng, tấn công giả lập thiết bị hoặc HKS, tấn công lặp lại, sử dụng lại phản hồi, thiết bị proxy được sử dụng để giả mạo chứng nhận	LPADB, RASP	Được sử dụng làm đầu vào cho DCVDB, cần LPADB để tăng khả năng chống lại các khóa KeyAttestation bị rò rỉ công khai

PlayIntegrity	tái đóng gói & giả mạo & làm giả ứng dụng, tấn công lặp lại, sử dụng lại phản hồi, chứng thực proxy, tấn công hạ cấp ứng dụng, các phiên bản ứng dụng cũ dễ bị tấn công được tải bên cạnh, root qua bộ nạp khởi động đã mở khóa, hình ảnh hệ thống không xác định (ví dụ: ROM tùy chỉnh), mất quyền tin cậy (ví dụ: trình tự khởi động bị thao túng) + phán quyết MDVM của backend độc quyền của Google để xác định các thiết bị bị xâm phạm, các công cụ đánh cắp thông tin xác thực, tự động hóa đầu vào/bot, tấn công lớp phủ (ví dụ: tapjacking), có thể được sử dụng để thực thi các chính sách cập nhật bảo mật (MEETS_STRONG_INTEGRITY yêu cầu bản vá bảo mật trong 12 tháng gần nhất)	KeyAttestation, RASP	Trạng thái bộ nạp khởi động cần được kiểm tra để tin tưởng các phán quyết PlayIntegrity, Không chắc chắn về độ tin cậy → không rõ cách đánh giá trong backend của Google hoạt động (cũng được biết là thường bị cộng đồng root mã nguồn mở nhắm mục tiêu bằng cách sử dụng các khóa KeyAttestation bị rò rỉ)
iOS DC Device Check	tấn công lặp lại, giả mạo chứng chỉ, proxy thiết bị được sử dụng để làm giả chứng thực, tái đóng gói & giả mạo & làm giả ứng dụng, bản dựng gỡ lỗi bị rò rỉ, không rõ từ tài liệu những mối đe dọa bổ sung nào có thể được giảm thiểu	RASP	DeviceCheck cần các biện pháp bảo mật bổ sung vì nó không chứng thực tính toàn vẹn của thiết bị → RASP
Cơ sở dữ liệu khóa chứng thực nền tảng bị rò rỉ (LPADB)	rooting dựa trên việc mở khóa bộ nạp khởi động bằng cách sử dụng các khóa chứng thực bị rò rỉ công khai để che giấu	KeyAttestation	-
Cơ sở dữ liệu lỗ hổng lớp thiết bị (DCVDB)	các thiết bị người dùng không an toàn do các lỗ hổng được biết đến công khai, ví dụ: root/leo thang đặc quyền cục bộ, TEE, khai thác bộ nạp khởi động/chuỗi tin cậy	KeyAttestation, RASP	DCVDB chỉ hiệu quả như việc xác định đúng lớp thiết bị
Bảo vệ tự thân ứng dụng thời gian chạy (RASP)	Hooking/gỡ lỗi ứng dụng & Tái đóng gói & giả mạo, UD root & giả lập	-	RASP cung cấp một cách để liên tục và động giám sát ứng dụng và thiết bị của người dùng về tính toàn vẹn và xác thực trong khi ứng dụng đang chạy. Ngoài ra, nó cung cấp một khuôn khổ phát hiện thay thế hoạt động độc lập với các cơ chế nền tảng.

Tín hiệu KeyAttestation của Android¶

Tín hiệu	Thực thi	Chi tiết	Giá trị ví dụ	Các mối đe dọa đã giảm thiểu	Sử dụng bổ sung	Kiểm tra tính hợp lý
SecurityLevel	Hardwareenforced	xác định loại HKS	TrustedEnvironment hoặc StrongBox	tấn công giả lập, ví dụ: giả lập thiết bị hoặc kho khóa	đảm bảo khóa được lưu trữ trong kho khóa an toàn	đã sử dụng, luôn phải giống nhau
attestationIdModel	Hardwareenforced	xác định mẫu thiết bị	ví dụ: "SM-A146P" cho Samsung Galaxy A14 5G	sao chép ứng dụng	được sử dụng để xác định lớp thiết bị	đã sử dụng, luôn phải giống nhau
attestationIdProduct	Hardwareenforced	xác định mẫu thiết bị (thuộc tính nguồn thay thế)	ví dụ: "a14xmeea" cho Samsung Galaxy A14 5G	sao chép ứng dụng	được sử dụng để xác định lớp thiết bị	đã sử dụng, luôn phải giống nhau
attestationIdDevice	Hardwareenforced	xác định mẫu thiết bị (thuộc tính nguồn thay thế)	ví dụ: "a14xm" cho Samsung Galaxy A14 5G	sao chép ứng dụng	được sử dụng để xác định lớp thiết bị	đã sử dụng, luôn phải giống nhau
osVersion	Hardwareenforced	xác định phiên bản hệ điều hành	ví dụ: "130000" cho Android 13	sao chép ứng dụng, tấn công hạ cấp	được sử dụng để xác định lớp thiết bị	đã sử dụng, chỉ có thể tăng, không giảm
osPatchLevel	Hardwareenforced	xác định mức độ vá lỗi bảo mật hiện tại	ví dụ: "202508" cho mức độ vá lỗi bảo mật tháng 8 năm 2025	-	được sử dụng để xác định lớp thiết bị	đã sử dụng, chỉ có thể tăng, không giảm
RootOfTrust. deviceLocked	Hardwareenforced	xác định trạng thái bộ nạp khởi động hiện tại	ví dụ: "true" nếu thiết bị khởi động một hình ảnh đã ký và được Verified Boot xác minh thành công	root qua bộ nạp khởi động đã mở khóa, hình ảnh hệ thống không xác định (ví dụ: ROM tùy chỉnh), mất quyền tin cậy (ví dụ: trình tự khởi động bị thao túng)	-	không sử dụng
RootOfTrust. verifiedBootState	Hardwareenforced	xác định trạng thái Verified Boot của thiết bị	ví dụ: "Verified" cho quyền tin cậy gốc được xác minh đầy đủ	root qua bộ nạp khởi động đã mở khóa, hình ảnh hệ thống không xác định (ví dụ: ROM tùy chỉnh), mất quyền tin cậy (ví dụ: trình tự khởi động bị thao túng), tấn công giả lập	-	không sử dụng
attestationChallenge	Hardwareenforced	thách thức do máy chủ cung cấp	độ dài tối đa 128 byte	tấn công lặp lại, sử dụng lại phản hồi, proxy thiết bị được sử dụng để làm giả chứng thực	-	không sử dụng
AttestationApplicationId. AttestationPackageInfo. package_name	Softwareenforced	xác định các ứng dụng được phép sử dụng tài liệu khóa bí mật dưới sự chứng thực	ví dụ: "org.sprind.wallet"	tái đóng gói & giả mạo & làm giả ứng dụng	-	không sử dụng
AttestationApplicationId. AttestationPackageInfo. version	Softwareenforced	xác định "versionCode" của ứng dụng từ thuộc tính bản dựng	ví dụ: "1"	tấn công hạ cấp ứng dụng, các phiên bản ứng dụng cũ dễ bị tấn công được tải bên cạnh	-	đã sử dụng, chỉ có thể tăng, không giảm
AttestationApplicationId. signature_digests	Softwareenforced	tập hợp các giá trị băm SHA-256 của các chứng chỉ ký của ứng dụng	giá trị băm SHA-256 được mã hóa Base64	tái đóng gói & giả mạo & làm giả ứng dụng	-	không sử dụng

Lưu ý:

• "attestationIdModel", "attestationIdProduct" và "attestationIdDevice" đều có thể được sử dụng để xác định mẫu thiết bị cho việc xác định lớp thiết bị. Cả ba đều được bao gồm vì các thử nghiệm đã chỉ ra rằng một số thiết bị không cung cấp tất cả các giá trị này. Để tăng khả năng xác định mẫu thông qua chứng thực khóa, cả ba trường này nên được đánh giá.
• Chữ ký chứng thực khóa và chứng chỉ (bao gồm toàn bộ chuỗi chứng chỉ) phải được xác thực để dựa vào các tín hiệu như đã mô tả. Danh sách thu hồi của Google cho các chứng chỉ chứng thực khóa cũng nên được kiểm tra. Tuy nhiên, danh sách không được cập nhật đủ thường xuyên và thường xuyên có các khóa bị rò rỉ có sẵn công khai mà vẫn có thể được sử dụng để ký chứng thực khóa nhưng chưa bị Google thu hồi.
• Chứng thực khóa Android cũng bao gồm thông tin bổ sung về các thuộc tính của khóa được chứng thực, chẳng hạn như yêu cầu xác thực người dùng để sử dụng khóa hoặc mục đích của khóa (ký, mã hóa, v.v.). Các khía cạnh này không được ghi lại trong danh sách này, vì chúng không giảm thiểu một mối đe dọa cụ thể đối với ứng dụng hoặc thiết bị. Tuy nhiên, chúng rất quan trọng và phải được xác minh khi đánh giá chứng thực khóa.

Tín hiệu Phán quyết PlayIntegrity của Android¶

Tín hiệu	Nhà cung cấp	Chi tiết	Giá trị mẫu	Các mối đe dọa đã giảm thiểu	Kinh nghiệm thu thập	Kiểm tra tính hợp lý
requestDetails. requestPackageName	OS	Tên gói mà yêu cầu khai báo là nguồn gốc; Play Integrity xác minh rằng nó khớp với ứng dụng gọi + chứng chỉ ký	ví dụ: "org.sprind.wallet"	đóng gói lại ứng dụng & giả mạo & ăn cắp danh tính	-	không sử dụng
requestDetails. nonce	Wallet Backend	Giá trị ngẫu nhiên do backend của bạn tạo ra để ngăn chặn tấn công replay; được trả lại nguyên trạng trong kết quả	mã hóa base64 16–32 byte	Tấn công replay, sử dụng lại phản hồi, xác nhận proxy	-	không sử dụng
requestDetails. timestamp	Google	Thời điểm Google tạo ra kết quả	ví dụ: "1672531199000" (Unix ms)	Tấn công replay, sử dụng lại phản hồi, xác nhận proxy	-	không sử dụng
appIntegrity. appRecognitionVerdict	Google	Liệu ứng dụng có được nhận dạng là gốc, không bị sửa đổi, được cài đặt hợp lệ hay không	ví dụ: "PLAY_RECOGNIZED"	đóng gói lại ứng dụng & giả mạo & ăn cắp danh tính, tải xuống bên (không chủ ý?)	-	không sử dụng
appIntegrity. packageName	Google	Gói thực tế mà Google nhìn thấy khi thực thi yêu cầu (cũng từ KeyAttestation)	ví dụ: "org.sprind.wallet"	đóng gói lại ứng dụng & giả mạo & ăn cắp danh tính	-	không sử dụng
appIntegrity. certificateSha256Digest	Google	Tóm tắt SHA-256 của chứng chỉ ký của ứng dụng (cũng từ KeyAttestation)	Tóm tắt SHA-256 được mã hóa Base64	đóng gói lại ứng dụng & giả mạo & ăn cắp danh tính	-	không sử dụng
appIntegrity. versionCode	Google	Xác định "versionCode" của ứng dụng từ các thuộc tính build (cũng từ KeyAttestation)	ví dụ: "1"	tấn công hạ cấp ứng dụng, các phiên bản ứng dụng dễ bị tấn công cũ hơn được tải xuống bên	-	có thể được sử dụng, chỉ có thể tăng, không thể giảm
deviceIntegrity. deviceRecognitionVerdict	Google	Mô tả mức độ tin cậy của thiết bị	ví dụ: "MEETS_STRONG_INTEGRITY"	rooting qua bootloader bị mở khóa, hình ảnh hệ thống không xác định (ví dụ: ROM tùy chỉnh), mất gốc tin cậy (ví dụ: chuỗi khởi động bị thao túng) + kết quả MDVM backend độc quyền của Google để xác định các thiết bị bị xâm phạm (chúng tôi không biết họ thực sự làm gì trong backend của họ)	có	không sử dụng
deviceIntegrity. deviceAttributes. sdkVersion	Google	Cấp độ API của SDK Android (Phiên bản hệ điều hành) của thiết bị	ví dụ: "33" cho Android 13,	nhân bản ứng dụng, tấn công hạ cấp	-	có thể được sử dụng, chỉ có thể tăng, không thể giảm
deviceIntegrity. recentDeviceActivity. deviceActivityLevel	Google	các yêu cầu mã thông báo tính toàn vẹn trên thiết bị này trong giờ qua cho mỗi ứng dụng	ví dụ: "LEVEL_1" đến "LEVEL_4"	Lưu lượng bot, trang trại giả lập, proxy thiết bị để giả mạo kết quả	có	không sử dụng
accountDetails. appLicensingVerdict	Google	Chỉ ra liệu ứng dụng có được cài đặt từ PlayStore hay không	ví dụ: "LICENSED", "UNLICENSED", "UNEVALUATED"	tệp APK tải xuống bên mà không có quyền (không chủ ý?)	có	không sử dụng
environmentDetails. appAccessRiskVerdict. appsDetected	Google	Danh sách các ứng dụng khác được phát hiện có thể chụp, phủ lên, kiểm soát hoặc can thiệp vào ứng dụng của bạn (trình ghi màn hình, phần mềm độc hại phủ, công cụ tự động hóa, v.v.)	ví dụ: "KNOWN_CAPTURING", "UNKNOWN_CONTROLLING"	Công cụ đánh cắp thông tin đăng nhập, tự động hóa/bot đầu vào, tấn công phủ (ví dụ: tapjacking)	có	có thể
environmentDetails. playProtectVerdict	Google	Chỉ ra đánh giá rủi ro của thiết bị/ứng dụng của Play Protect	ví dụ: "NO_ISSUES" hoặc "MEDIUM_RISK"	Sử dụng các thiết bị có phần mềm độc hại đã biết, Play Protect bị vô hiệu hóa (đây là lựa chọn có thể của người dùng)	có	có thể

Ghi chú:

• Vì phiên bản Android tối thiểu của chúng tôi sẽ là Android 13, chúng tôi sẽ kiểm tra "MEETS_STRONG_INTEGRITY", và bảng trên dựa trên khả năng của kết quả Play Integrity được hỗ trợ bởi phần cứng.
• MEETS_STRONG_INTEGRITY cũng bao gồm yêu cầu thiết bị đã nhận được bản vá bảo mật trong vòng 12 tháng qua.
• Chữ ký kết quả PlayIntegrity phải được xác thực và kết quả cần được giải mã (sử dụng khóa được cung cấp qua Google Play Console) để dựa vào các tín hiệu như đã mô tả.

Android RASP¶

Vì chúng tôi chưa quyết định về một giải pháp RASP, các tính năng phát hiện được ghi lại nên được coi là một bộ yêu cầu sơ bộ cho các giải pháp RASP tiềm năng.

Tính năng phát hiện	Chi tiết	Các mối đe dọa đã giảm thiểu
Hooking/gỡ lỗi ứng dụng	Giám sát việc đính kèm trình gỡ lỗi động, tiêm thư viện, các framework đo lường (Frida, Xposed, LSPosed, DobbyHook) và các hình thức thao túng logic thời gian chạy động khác.	Kỹ thuật đảo ngược, thao túng thời gian chạy động
Đóng gói lại ứng dụng	Phát hiện các sửa đổi đối với gói ứng dụng, ký lại bằng các chứng chỉ không được ủy quyền hoặc các framework đã tiêm trước khi cài đặt.	đóng gói lại ứng dụng & giả mạo & ăn cắp danh tính
Tampering ứng dụng	Xác định các bản vá nhị phân, các phân đoạn mã đã thay đổi, các thay đổi tệp bất ngờ và các sửa đổi đối với logic quan trọng.	Các biện pháp bảo vệ bị vô hiệu hóa, logic đã vá
Root UD	Phát hiện các chỉ báo root như vi phạm sandbox, truy cập tệp đặc quyền, các bộ công cụ đã tiêm và các khả năng của hệ điều hành nâng cao.	Leo thang đặc quyền, hooking không giới hạn, bỏ qua các kiểm soát tính toàn vẹn và cô lập sandbox
Giả lập UD	Phát hiện thực thi trong môi trường ảo hóa, tự động hóa hoặc phần cứng không thực thông qua kiểm tra hành vi hệ thống và xác minh tính nhất quán của phần cứng.	Gian lận tự động hóa, tấn công bot, thiết bị giả mạo

Ghi chú:

• RASP cung cấp một cách để liên tục và động giám sát ứng dụng và thiết bị của người dùng về tính toàn vẹn và xác thực trong khi ứng dụng đang chạy.
• Việc phát hiện root bởi RASP đặc biệt quan trọng trong môi trường Android, vì có các phương pháp được công khai và ghi chép rõ ràng sử dụng các khóa key-attestation bị rò rỉ để mô phỏng một thiết bị có bootloader bị khóa, ngay cả khi nó đang chạy một hình ảnh hệ thống đã sửa đổi (ví dụ: hình ảnh hệ thống đã root). Cơ chế phát hiện root này hoạt động kết hợp với danh sách chặn được duy trì độc lập, tách biệt với danh sách thu hồi của Google, đối với các khóa key-attestation bị rò rỉ công khai chưa bị Google thu hồi. Nó đặc biệt nhằm mục đích làm rào cản chống lại việc sử dụng các khóa key-attestation không bị rò rỉ công khai.

iOS DCDeviceCheck.AppAttest Attestation¶

Tín hiệu	Nhà cung cấp	Chi tiết	Giá trị ví dụ	Các mối đe dọa đã giảm thiểu	Kiểm tra tính hợp lý
attestationObject (x5c)	Secure Enclave + Máy chủ xác thực của Apple	Đối tượng CBOR chứng minh rằng khóa App Attest đã được tạo trong SecureEnclave	Cấu trúc CBOR nhị phân	Các cuộc tấn công phát lại, giả mạo chứng chỉ, không rõ từ tài liệu những mối đe dọa bổ sung nào có thể được giảm thiểu, cũng có thể xác định việc đóng gói lại & giả mạo & giả mạo ứng dụng, giả lập thiết bị, thời gian chạy đã giả mạo, hệ điều hành đã bẻ khóa (root)	không sử dụng
credentialId	Secure Enclave	Mã định danh duy nhất 32 byte cho khóa App Attest được tạo trong Secure Enclave	Chuỗi Base64	Sao chép khóa hoặc proxy thiết bị được sử dụng để giả mạo xác thực	đã sử dụng, đã kiểm tra so với xác nhận
clientDataHash	Backend của Ví	Băm SHA-256 của yêu cầu do máy chủ cung cấp	Tóm tắt 32 byte	Các cuộc tấn công phát lại, sử dụng lại phản hồi, proxy thiết bị được sử dụng để giả mạo xác thực	không sử dụng
RP ID	Hệ điều hành + Secure Enclave	Tiền tố App ID của ứng dụng của bạn, một dấu chấm và CFBundleIdentifier của bạn	ví dụ: SHA‑256( TeamID + "." + BundleID )	đóng gói lại & giả mạo & giả mạo ứng dụng	không sử dụng
environment (aaguid)	Hệ điều hành + Secure Enclave	Chỉ ra liệu khóa có đến từ môi trường "development" hay "production"	ví dụ: "production"	các bản dựng gỡ lỗi bị rò rỉ	không sử dụng
counter	Secure Enclave	Đếm số lần khóa đã được sử dụng để ký, PHẢI là 0 cho việc xác thực	"0"	Không rõ ý nghĩa nếu bộ đếm không bằng 0	ban đầu được lưu trữ để điền vào DB

Ghi chú:

• Việc xác thực cũng bao gồm một biên lai có thể được sử dụng để truy vấn chỉ số rủi ro từ máy chủ của Apple. Tài liệu của Apple mô tả chỉ số này như sau: "Biên lai đại diện cho chỉ số dưới dạng một chuỗi cho biết số lượng khóa đã được xác thực liên quan đến một thiết bị nhất định trong 30 ngày qua. Hãy tìm giá trị này là một số nhỏ." Chỉ số này có thể giúp xác định các thiết bị đang được sử dụng để tạo ra các xác thực hoặc xác nhận thay mặt cho các thiết bị khác (mối đe dọa xác thực proxy). Tuy nhiên, nó có những hạn chế đáng kể: cả chỉ số và ngưỡng mong đợi đều không được xác định rõ ràng, và việc sử dụng nó yêu cầu backend của chúng tôi giao tiếp với máy chủ của Apple, điều này gây ra thêm rủi ro về quyền riêng tư do khả năng theo dõi từ phía Apple. Để biết thêm thông tin, vui lòng xem mô tả của WardenSupreme về tính năng này.
• iOS không cung cấp bất kỳ thông tin nào dựa trên phần cứng về mẫu thiết bị hoặc phiên bản/bản vá hệ điều hành. Các giá trị này phải được truy vấn từ hệ điều hành sau khi đảm bảo rằng thiết bị và hệ điều hành chưa bị giả mạo.

Xác nhận DCDeviceCheck.AppAttest của iOS¶

Tín hiệu	Nhà cung cấp	Chi tiết	Giá trị ví dụ	Các mối đe dọa đã giảm thiểu	Sử dụng bổ sung	Kiểm tra tính hợp lý
assertionObject	Secure Enclave	Đối tượng CBOR chứa chữ ký trên yêu cầu + trạng thái với khóa App Attest	Cấu trúc CBOR nhị phân	Các cuộc tấn công phát lại, giả mạo chứng chỉ, không rõ từ tài liệu những mối đe dọa bổ sung nào có thể được giảm thiểu, cũng có thể xác định việc đóng gói lại & giả mạo & giả mạo ứng dụng, giả lập thiết bị, thời gian chạy đã giả mạo, hệ điều hành đã bẻ khóa (root)	-	Phải xác thực chữ ký bằng khóa công khai đã xác thực
keyId (khớp với credentialId)	Secure Enclave	Định danh của khóa App Attest được sử dụng để ký xác nhận	Chuỗi Base64	Sao chép ứng dụng, proxy thiết bị được sử dụng để giả mạo xác thực	-	Phải khớp với keyId đã xác thực đã biết (credentialId từ việc xác thực)
clientDataHash	Backend của Ví	Băm SHA-256 của yêu cầu do máy chủ tạo và tải trọng tùy chọn	Tóm tắt 32 byte	Các cuộc tấn công phát lại, sử dụng lại phản hồi	-	không sử dụng
RP ID	Hệ điều hành + Secure Enclave	Tiền tố App ID của ứng dụng của bạn, một dấu chấm và CFBundleIdentifier của bạn	ví dụ: SHA‑256( TeamID + "." + BundleID )	đóng gói lại & giả mạo & giả mạo ứng dụng	-	không sử dụng
counter	Secure Enclave	Đếm số lần khóa đã được sử dụng để ký	"42"	Các cuộc tấn công phát lại, sử dụng lại phản hồi, proxy thiết bị được sử dụng để giả mạo xác thực	-	Bộ đếm được yêu cầu tăng đơn điệu. Các bước nhảy lớn có thể cho thấy ứng dụng/thiết bị được sử dụng để xác thực proxy cho ứng dụng/thiết bị khác, giá trị thấp hơn điểm đã ghi lại cho thấy một cuộc tấn công phát lại.

iOS RASP¶

Vì chúng tôi chưa quyết định giải pháp RASP nào, các tính năng phát hiện được ghi lại nên được coi là một tập hợp các yêu cầu sơ bộ cho các giải pháp RASP tiềm năng.

Tính năng phát hiện	Chi tiết	Các mối đe dọa đã giảm thiểu
Hooking/gỡ lỗi ứng dụng	Giám sát việc đính kèm trình gỡ lỗi động, tiêm thư viện, các framework instrument (Frida, Substrate) và các hình thức thao túng động khác đối với logic thời gian chạy.	Kỹ thuật đảo ngược, thao túng thời gian chạy động
Đóng gói lại ứng dụng	Phát hiện các sửa đổi đối với gói ứng dụng, ký lại bằng chứng chỉ không được ủy quyền hoặc các framework đã tiêm trước khi cài đặt.	đóng gói lại & giả mạo & giả mạo ứng dụng
Tampering ứng dụng	Xác định các bản vá nhị phân, các phân đoạn mã đã thay đổi, các thay đổi tệp không mong muốn và các sửa đổi đối với logic quan trọng.	Bảo vệ bị vô hiệu hóa, logic đã vá
Root UD	Phát hiện các chỉ báo bẻ khóa như vi phạm sandbox, truy cập tệp đặc quyền, các chuỗi công cụ đã tiêm và các khả năng của hệ điều hành được nâng cao.	Leo thang đặc quyền, hooking không hạn chế, truy cập keychain, bỏ qua các kiểm soát tính toàn vẹn.
Giả lập UD	Phát hiện thực thi trong môi trường ảo hóa, tự động hóa hoặc phần cứng không có thật thông qua kiểm tra hành vi hệ thống và xác minh tính nhất quán của phần cứng.	Gian lận tự động hóa, tấn công bot, thiết bị giả mạo

Ghi chú:

• Bảo mật nền tảng của Apple cung cấp các biện pháp bảo vệ mạnh mẽ tại thời điểm cài đặt: App Sandbox & Code Signing, App Store Review (ngăn các ứng dụng độc hại hoặc đã ký lại rõ ràng xâm nhập vào cửa hàng), System Integrity Protection (ngăn thực thi mã không được ký trên các thiết bị không bị bẻ khóa). Dựa trên chức năng được ghi lại của các tính năng này, chúng không cung cấp thông tin về hoặc bảo vệ chống lại: Rooting (Bẻ khóa) hoặc đặc quyền được nâng cao, hooking hoặc instrument thời gian chạy.
  • “Ứng dụng của bạn sử dụng dịch vụ App Attest để xác nhận tính xác thực của nó. Một phiên bản ứng dụng bị xâm phạm chạy trên thiết bị Apple chính hãng, chưa sửa đổi không thể tạo ra các xác nhận hợp lệ." Tài liệu của Apple
• RASP cung cấp một cách để liên tục và động theo dõi ứng dụng và thiết bị của người dùng về tính toàn vẹn và xác thực trong khi ứng dụng đang chạy.