Sinh trắc học và Nhận thức của người thanh toán trong Liên kết động

Phương pháp của Corbado kết hợp passkey chống phishing (SCA) với màn hình hiển thị do ngân hàng kiểm soát và liên kết động phía máy chủ để đáp ứng Điều 5 của PSD2 RTS (“những-gì-bạn-thấy-là-những-gì-bạn-ký”).

• Triển khai cốt lõi (hiện tại): Chúng tôi hiển thị số tiền và người thụ hưởng của giao dịch trong giao diện người dùng (UI) do Bison‑Bank kiểm soát ngay trước và trong khi xác thực bằng passkey. Backend của chúng tôi tạo ra một thử thách dùng một lần được ràng buộc với một bản ghi chính tắc của giao dịch (số tiền, người thụ hưởng, txnId). Phản hồi chỉ được chấp nhận nếu khớp với bản ghi đó; bất kỳ thay đổi nào cũng làm mất hiệu lực của nó.

• Quan điểm pháp lý: Liên kết động vẫn là yêu cầu bắt buộc cho các khoản thanh toán từ xa ngay cả khi sử dụng passkey (PSD2 Điều 97(2); RTS Điều 5). RTS không yêu cầu “mã xác thực” của liên kết động phải được tính toán trên thiết bị; việc tạo/xác thực phía máy chủ là chấp nhận được khi tính toàn vẹn của hiển thị, tính cụ thể và vô hiệu hóa khi có thay đổi được thực thi (xem thêm EBA Q&A 2020_5366 về nơi mã có thể được tính toán).

• Bảo mật & khả năng kiểm toán: Ràng buộc một chữ ký passkey dựa trên phần cứng, chống phishing với dữ liệu giao dịch cụ thể sẽ ngăn chặn việc giả mạo và chuyển tiếp, và tạo ra bằng chứng mạnh mẽ, không thể chối cãi về sự đồng ý của người thanh toán. Khi được hỗ trợ, chúng tôi có thể tùy chọn áp dụng Xác nhận Thanh toán An toàn (Secure Payment Confirmation - SPC) để thêm bằng chứng mã hóa về các chi tiết đã hiển thị mà không thay đổi mô hình backend.

• SCA: Hai yếu tố độc lập từ các loại riêng biệt (kiến thức/sở hữu/vốn có), được bảo vệ chống lại việc tiết lộ/sao chép với các biện pháp giảm thiểu phù hợp (RTS Điều 6–8). Yêu cầu tính độc lập (Điều 9), bao gồm cả việc tách biệt khi thực hiện trên các thiết bị đa năng (ví dụ: bảo vệ cấp hệ điều hành, phần cứng bảo mật).
• Liên kết động (RTS Điều 5):
  • (i) người thanh toán được biết về số tiền và người thụ hưởng trong quá trình xác thực
  • (ii) mã xác thực là duy nhất cho số tiền/người thụ hưởng đó
  • (iii) bất kỳ thay đổi nào cũng làm mã không hợp lệ
  • (iv) tính bảo mật/toàn vẹn của số tiền, người thụ hưởng và mã được bảo vệ từ đầu đến cuối. Điều này mang lại ý định pháp lý “những-gì-bạn-thấy-là-những-gì-bạn-ký”.
• Hàm ý: Chỉ xác thực người dùng mạnh là không đủ cho các khoản thanh toán. Sự chấp thuận phải được ràng buộc với dữ liệu giao dịch cụ thể với bằng chứng có thể kiểm toán về sự ràng buộc và việc hiển thị cho người thanh toán (RTS Điều 5(1)(a–d)).

Làm rõ — phishing và ủy quyền: Passkey được ràng buộc với nguồn gốc, vì vậy các tên miền giả mạo không thể lấy được chữ ký hợp lệ. Tuy nhiên, PSD2 vẫn yêu cầu liên kết động cho các khoản thanh toán từ xa để ràng buộc sự ủy quyền với số tiền và người thụ hưởng chính xác nhằm vô hiệu hóa bất kỳ thay đổi nào và để bảo vệ tính toàn vẹn của những gì được hiển thị cho người thanh toán (RTS Điều 5(1)(a–d)). Liên kết động giải quyết tính toàn vẹn của việc ủy quyền (bao gồm cả việc thay thế MITM/MITB/TPP), chứ không chỉ phishing.

Ý kiến của EBA năm 2019 (EBA‑Op‑2019‑06) củng cố rằng liên kết động ràng buộc việc xác thực với số tiền và người thụ hưởng, yêu cầu sự độc lập của các yếu tố và chấp nhận các khóa mã hóa ràng buộc với thiết bị là yếu tố sở hữu khi có sự ràng buộc thiết bị duy nhất. Nó cũng nhấn mạnh tính toàn vẹn của những gì được hiển thị cho người thanh toán trong quá trình xác thực. Ý kiến của EBA 2019

Trước khi có PSD2, nhiều ngân hàng dựa vào OTP qua SMS hoặc danh sách TAN được in ra giấy mà thường không hiển thị số tiền hoặc người thụ hưởng cùng với bước phê duyệt. Lỗ hổng đó đã giúp kẻ gian dễ dàng lừa khách hàng ủy quyền cho các giao dịch chuyển tiền không mong muốn một khi thông tin đăng nhập bị đánh cắp. Liên kết động được giới thiệu để lấp đầy lỗ hổng đó bằng cách đảm bảo người thanh toán nhận biết được số tiền và người thụ hưởng chính xác tại thời điểm xác thực và bằng cách làm cho mã xác thực cụ thể cho các chi tiết đó để bất kỳ thay đổi nào cũng làm mất hiệu lực của nó (RTS Điều 5(1)(a–d)). Khi SMS là một phần của quy trình, các tổ chức phát hành cũng phải đảm bảo tính bảo mật, xác thực và toàn vẹn của số tiền/người thụ hưởng và mã trong tất cả các giai đoạn xác thực (Q&A 2018_4414; RTS Điều 5(2)). Các phương thức phê duyệt trong ứng dụng ngày nay (ví dụ: “Bạn có muốn ủy quyền 100 USD cho John Smith qua Face ID không?”) thực hiện nguyên tắc “những gì bạn thấy là những gì bạn ký” này một cách thân thiện với khách hàng.

Ngày nay, trên di động, có hai mô hình chiếm ưu thế. Đầu tiên, một thông báo đẩy có thể liên kết sâu (deep-link) khách hàng vào ứng dụng để xem lại chi tiết giao dịch và phê duyệt. Các cơ quan giám sát đã làm rõ rằng thông báo đẩy có thể dùng làm bằng chứng cho yếu tố sở hữu nếu các biện pháp kiểm soát của Điều 7 được áp dụng để giảm thiểu việc sử dụng trái phép và ngăn chặn sao chép, và toàn bộ hành trình tuân thủ RTS; tuy nhiên, rủi ro tấn công phi kỹ thuật vẫn còn và cần được giải quyết trong UX (Q&A 2019_4984; RTS Điều 7).

Thứ hai, việc phê duyệt sử dụng sinh trắc học gốc của thiết bị (với phương án dự phòng là mã PIN) thực hiện xác minh người dùng cục bộ để mở khóa một hoạt động khóa riêng. Khóa riêng nằm trong một môi trường phần cứng an toàn (Secure Enclave/TEE/TPM) và ký vào một thử thách. Điều này tương ứng rõ ràng với SCA: yếu tố vốn có (sinh trắc học) cộng với yếu tố sở hữu được chứng minh bằng việc ràng buộc thiết bị và một khóa mã hóa ràng buộc với thiết bị (EBA‑Op‑2019‑06, đoạn 25, 35–37). Đối với các khoản thanh toán từ xa, mã phải được liên kết động với số tiền và người thụ hưởng và các chi tiết đó phải được hiển thị cho người thanh toán trước khi xác minh người dùng (RTS Điều 5). Nếu cả hai yếu tố đều trên một thiết bị, hãy triển khai các môi trường thực thi an toàn riêng biệt và kiểm tra tính toàn vẹn để việc xâm phạm một yếu tố không làm xâm phạm yếu tố kia (RTS Điều 9(2)–(3)).

Về bản chất, sinh trắc học cục bộ không “xác thực với ngân hàng” một cách trực tiếp. Thay vào đó, sinh trắc học (hoặc mã PIN dự phòng) thực hiện xác minh người dùng trên thiết bị và kiểm soát quyền truy cập vào một khóa riêng không thể xuất được lưu trữ trong một mô-đun bảo mật dựa trên phần cứng. Khi người thanh toán phê duyệt, thiết bị sử dụng khóa riêng đó để tạo ra một chữ ký số trên một thử thách do ngân hàng cung cấp. Nếu ngân hàng lấy hoặc liên kết thử thách đó với một bản ghi chính tắc của giao dịch (số tiền, người thụ hưởng, mã định danh), thì chữ ký kết quả sẽ hoạt động như một mã xác thực cụ thể cho các chi tiết đó. Bất kỳ thay đổi nào cũng sẽ làm mất hiệu lực của mã vì bản ghi được lưu trữ không còn khớp nữa, hoặc, trong các thiết kế nâng cao, vì việc tạo thử thách thay đổi. Phần nhận thức của người thanh toán vẫn là một yêu cầu về UX: hiển thị số tiền và người thụ hưởng trong một giao diện do ngân hàng kiểm soát ngay trước khi xác minh người dùng. Cùng với nhau, điều này thỏa mãn các yêu cầu của RTS Điều 5 về nhận thức, tính cụ thể/duy nhất và vô hiệu hóa khi có thay đổi, trong khi các biện pháp kiểm soát của Điều 7 và bằng chứng ràng buộc thiết bị chứng minh yếu tố sở hữu.

• Sở hữu (khóa ràng buộc với thiết bị & đồng bộ hóa): Khóa riêng của passkey được lưu trữ trong phần cứng bảo mật (TEE/Secure Enclave/TPM). Passkey ràng buộc với thiết bị không thể xuất được, phù hợp với kỳ vọng của EBA về việc ràng buộc thiết bị duy nhất (EBA‑Op‑2019‑06, đoạn 25, 35–37). Passkey được đồng bộ hóa cũng có thể chứng minh yếu tố sở hữu trong mỗi lần xác thực, miễn là các biện pháp kiểm soát ràng buộc thiết bị và chống sao chép có hiệu quả; các cơ quan quản lý đã nhấn mạnh sự cần thiết của một liên kết đáng tin cậy giữa yếu tố và thiết bị (EBA‑Op‑2019‑06; RTS Điều 7).
• Vốn có/Kiến thức (Xác minh Người dùng): Xác minh Người dùng thông qua sinh trắc học (vốn có) hoặc mã PIN của thiết bị (kiến thức) sẽ kích hoạt khóa cục bộ. Kết hợp với yếu tố sở hữu, đây là xác thực hai yếu tố (2FA) thực sự với sự độc lập của các yếu tố. Việc vi phạm một yếu tố không làm ảnh hưởng đến yếu tố kia.

Liên kết động là về việc ràng buộc việc xác thực với giao dịch. Câu hỏi đối với một ngân hàng là: nếu chúng ta cho phép người dùng phê duyệt một khoản thanh toán qua passkey (thay vì, chẳng hạn, một OTP hoặc một thiết bị ký), liệu chúng ta có thể đảm bảo rằng sự phê duyệt này là cụ thể cho số tiền và người thụ hưởng dự định, và không thể bị tái sử dụng hoặc thao túng không?

Có 2 lựa chọn để triển khai liên kết động với passkey:

• Liên kết phía máy chủ (tiêu chuẩn): Tạo một thử thách WebAuthn dùng một lần mà backend liên kết với số tiền và người thụ hưởng chính xác. Người dùng thấy “€X cho Y” trong một giao diện do ngân hàng kiểm soát và phê duyệt bằng passkey. Phản hồi chỉ được chấp nhận cho giao dịch đó. Bất kỳ thay đổi nào cũng làm nó mất hiệu lực.
• Bao hàm mã hóa (nâng cao): Nhúng một hàm băm của số tiền/người thụ hưởng vào thử thách để chữ ký cam kết với dữ liệu giao dịch. Điều này không được RTS yêu cầu nhưng tăng thêm sự đảm bảo rằng ngay cả việc hoán đổi ở backend cũng sẽ thất bại khi xác minh.

Lưu ý tuân thủ rõ ràng: RTS không yêu cầu “mã xác thực” của liên kết động phải được tính toán trên thiết bị của người thanh toán. Một PSP có thể tạo và xác thực nó trên máy chủ miễn là số tiền/người thụ hưởng được bảo vệ và bất kỳ thay đổi nào cũng làm mất hiệu lực của mã (xem EBA Q&A 2020_5366 về vị trí/thời điểm của mã). Đó là cách tiếp cận liên kết động phía máy chủ (tiêu chuẩn) của chúng tôi.

Cả hai cách đều tạo ra một “mã xác thực” duy nhất, không thể tái sử dụng, cụ thể cho giao dịch. Lưu ý chính là nhận thức của người thanh toán: bản thân WebAuthn không chứng minh được những gì đã được hiển thị. Tính toàn vẹn của việc hiển thị phải đến từ giao diện người dùng do ngân hàng kiểm soát.

RTS Điều 5 yêu cầu người thanh toán phải thấy số tiền và người thụ hưởng trong quá trình xác thực. WebAuthn không chứng thực những gì đã được hiển thị. Về lý thuyết, nếu ứng dụng hoặc hệ điều hành bị xâm phạm, người dùng có thể bị đánh lừa trong khi trình xác thực vẫn ký. Chúng ta sẽ phân tích chi tiết bên dưới về cách rủi ro này diễn ra trong thực tế và tại sao nó không phải là một rủi ro bảo mật thực sự mà thiên về vấn đề diễn giải quy định hơn.

Các biện pháp kiểm soát tính toàn vẹn hiển thị mà chúng tôi thực thi:

• Giao diện do ngân hàng kiểm soát hiển thị số tiền + người thụ hưởng: chúng tôi chặn việc gọi passkey nếu giao diện bị che khuất hoặc mất tiêu điểm
• Phát hiện lớp phủ/giả mạo trong ứng dụng/web: không có lời nhắc passkey từ các iframe ẩn
• Kiểm soát tính toàn vẹn/attestation của thiết bị: từ chối hoặc yêu cầu xác thực tăng cường đối với các tín hiệu thiết bị đã bị root/jailbreak/xâm phạm
• Phê duyệt nguyên tử dựa trên một bản ghi số tiền/người thụ hưởng do máy chủ lưu giữ: một thử thách mới là bắt buộc khi có bất kỳ thay đổi tham số nào

Về bao hàm mã hóa: Các phần mở rộng “hiển thị giao dịch” của WebAuthn (SPC) chưa được hỗ trợ rộng rãi ngày nay. Nền tảng di động của chúng tôi là ràng buộc phía máy chủ, được củng cố bằng cách lấy thử thách từ bản ghi giao dịch (ví dụ: H(số tiền ‖ người thụ hưởng ‖ txnId ‖ nonce)) để chữ ký cam kết với các giá trị đó.

Cả hai mô hình đều sử dụng mật mã khóa công khai với các khóa thiết bị không thể xuất, và cả hai đều dựa vào việc xác minh người dùng cục bộ để mở khóa hoạt động ký. Trong cả hai trường hợp, ngân hàng đảm bảo nhận thức của người thanh toán bằng cách hiển thị số tiền và người thụ hưởng trong một giao diện do ngân hàng kiểm soát ngay trước khi xác minh người dùng, và đảm bảo tính cụ thể bằng cách ràng buộc mã xác thực với các chi tiết đó — làm mất hiệu lực của nó khi có bất kỳ thay đổi nào (RTS Điều 5(1)(a–d)). RTS không phụ thuộc vào công nghệ và không yêu cầu số tiền/người thụ hưởng phải được hiển thị bên trong một cửa sổ sinh trắc học của hệ điều hành; nó yêu cầu hiển thị cho người thanh toán và ràng buộc của mã (RTS Điều 5). Khi cả hai yếu tố SCA thực thi trên một thiết bị, các yêu cầu về tính toàn vẹn và tách biệt của Điều 9 áp dụng như nhau (RTS Điều 9(2)–(3)). Cuối cùng, vị trí của việc tính toán liên kết động là linh hoạt: nó có thể được thực hiện phía máy chủ nếu tính toàn vẹn được bảo toàn và bất kỳ thay đổi nào cũng làm mất hiệu lực của mã (Q&A 2020_5366). Đây là những điều kiện tương tự mà các cơ quan quản lý đã chấp nhận cho sinh trắc học cục bộ với PKI — do đó, passkey, được triển khai với cùng các biện pháp kiểm soát nhận thức của người thanh toán và ràng buộc, nên được chấp nhận trên cơ sở tương đương.

Vậy, passkey thông thường theo tiêu chuẩn WebAuthn có thực hiện được mục đích của liên kết động không? Một phần:

• Tấn công MITM/mạng: Có. Ràng buộc nguồn gốc và chữ ký cho mỗi thử thách ngăn chặn việc giả mạo và phát lại.
• Toàn vẹn giao dịch: Có. Liên kết máy chủ hoặc băm thử thách đảm bảo chỉ có số tiền/người thụ hưởng ban đầu mới được xác minh.
• Sự đồng thuận của người thanh toán: Khó hơn. Passkey thiếu hiển thị ở cấp trình xác thực. Lừa đảo giao diện người dùng trên các thiết bị bị xâm phạm có thể xảy ra. Cần phải xây dựng thêm một lớp bảo vệ để đảm bảo sự đồng thuận của người thanh toán.

Tại sao liên kết động vẫn cần thiết với passkey

• Pháp lý: PSD2 Điều 97(2) và RTS Điều 5 bắt buộc liên kết động cho tất cả các hoạt động khởi tạo thanh toán từ xa. Không có ngoại lệ cho các phương pháp chống phishing.
• Bảo mật: Passkey loại bỏ phishing chéo nguồn gốc, nhưng bản thân chúng không chứng minh được những gì đã được hiển thị cho người thanh toán. Liên kết động + các biện pháp kiểm soát tính toàn vẹn hiển thị đảm bảo rằng số tiền/người thụ hưởng cụ thể mà người dùng đã thấy là những gì ngân hàng thực hiện, và bất kỳ thay đổi nào cũng làm mất hiệu lực của sự phê duyệt.

Tóm lại, passkey có thể thỏa mãn liên kết động khi được ràng buộc chặt chẽ với dữ liệu giao dịch và kết hợp với các cơ chế hiển thị đáng tin cậy. Thách thức còn lại là chứng minh những gì người dùng đã thực sự nhìn thấy.

Corbado cung cấp một giải pháp tuân thủ liên kết động giải quyết rõ ràng các cân nhắc về sự đồng thuận của người thanh toán ở trên.

Quy trình:

• Hiển thị do ngân hàng kiểm soát cho người thanh toán thấy số tiền và người thụ hưởng chính xác. Không có lời nhắc passkey nào được hiển thị trừ khi giao diện này hiển thị.
• Xác thực: client gọi WebAuthn với một thử thách ràng buộc, dùng một lần cho giao dịch đã được chuẩn hóa. Trình xác thực thực hiện xác minh người dùng (sinh trắc học hoặc mã PIN của thiết bị) và ký trên thử thách và nguồn gốc.
• Xác minh phía máy chủ: backend xác minh hàm băm RP ID và nguồn gốc, khớp thử thách với giao dịch được lưu trữ, kiểm tra cờ UV/flags, thực thi sử dụng một lần và hết hạn, và so sánh bản ghi số tiền/người thụ hưởng đã lưu.
• Phê duyệt và kiểm toán: chỉ sau đó giao dịch mới được phê duyệt một cách nguyên tử. Bất kỳ sự không khớp/thay đổi nào đều bị từ chối và yêu cầu một lần xác thực mới. Một bản ghi kiểm toán không thể thay đổi được lưu lại (ID thông tin xác thực, authenticatorData, clientDataJSON, chữ ký, thử thách, và số tiền/người thụ hưởng đã được chuẩn hóa), tùy chọn được băm chuỗi để làm bằng chứng chống giả mạo.
• Cổng kiểm tra tính toàn vẹn thiết bị: Đánh giá tính toàn vẹn của thiết bị và tín hiệu attestation: từ chối hoặc yêu cầu xác thực tăng cường nếu thiết bị bị root/jailbreak/xâm phạm.
• Chuẩn hóa người thụ hưởng: Hiển thị một nhãn thân thiện (ví dụ: “ACME GmbH”), nhưng ràng buộc và xác minh dựa trên một mã định danh người thụ hưởng chính tắc (ví dụ: IBAN/BIC hoặc một lược đồ duy nhất khác).

Chi tiết kỹ thuật:

• Backend: tạo một đối tượng giao dịch với dữ liệu đã được chuẩn hóa (ví dụ: tiền tệ/số thập phân được chuẩn hóa; IBAN/người thụ hưởng được chuẩn hóa). Tạo một thử thách có thời hạn ngắn cam kết với các giá trị này (ví dụ: H(số tiền||người thụ hưởng||txnId||nonce)); lưu trữ đang chờ xử lý; chỉ tiết lộ ID không rõ ràng cho client.
• Client/trình xác thực: hiển thị chi tiết người thanh toán trong một giao diện do ngân hàng kiểm soát; gọi WebAuthn (RP ID = tên miền Bison) chỉ khi hiển thị; yêu cầu xác minh người dùng; trình xác thực ký thử thách + nguồn gốc theo WebAuthn.
• Xác minh/hoàn tất: xác thực chữ ký, hàm băm RP ID, nguồn gốc/loại, cờ UV; chống phát lại/hết hạn; so sánh bản ghi số tiền/người thụ hưởng không thể thay đổi; phê duyệt một cách nguyên tử; lưu lại bản ghi kiểm toán.
• Lấy thử thách từ bản ghi:: challenge = H(amount ‖ canonicalPayee ‖ txnId ‖ nonce)

Chính sách UX:

• Nhấn mạnh rõ ràng về số tiền/người thụ hưởng; các nút điều khiển xác nhận/hủy dễ tiếp cận; thời gian chờ ngắn; thử lại một cách nhẹ nhàng luôn sử dụng một thử thách mới; biên nhận ngay lập tức (ví dụ: “Bạn đã phê duyệt €X cho Y”). Chặn lời nhắc passkey nếu màn hình hiển thị bị che khuất và cảnh báo nếu các tham số thay đổi trước khi ký.
• Phát hiện lớp phủ/nội dung bị che khuất: không bao giờ hiển thị lời nhắc passkey nếu giao diện giao dịch không hiển thị. Từ chối nếu các tham số thay đổi giữa chừng và bắt đầu lại với một thử thách mới.

Lưu ý tuân thủ: Thiết kế từ đầu đến cuối này đáp ứng RTS Điều 5: nhận thức của người thanh toán (hiển thị do ngân hàng kiểm soát), tính cụ thể và duy nhất (mã dùng một lần ràng buộc với số tiền/người thụ hưởng), vô hiệu hóa khi có thay đổi (kiểm tra nghiêm ngặt phía máy chủ), và tính bảo mật/toàn vẹn của số tiền/người thụ hưởng và mã trong tất cả các giai đoạn (RTS Điều 5(1)(a–d), 5(2); xem thêm Q&A 2018_4414 về tính toàn vẹn của SMS). Tính độc lập của các yếu tố (Điều 7–9) được bảo toàn thông qua yếu tố sở hữu ràng buộc với thiết bị và xác minh người dùng cục bộ trên các thiết bị đa năng với các biện pháp bảo vệ phù hợp (RTS Điều 9(2)–(3)).

Lưu ý:* đối với các luồng web, Corbado sẽ tùy chọn áp dụng Secure Payment Confirmation nếu/khi Apple cung cấp hỗ trợ rộng rãi, bổ sung một màn hình hiển thị đáng tin cậy do trình duyệt trung gian chứng thực bằng mã hóa số tiền và người thụ hưởng.

Mối quan ngại: Tấn công phishing Phản hồi: Passkey có khả năng chống phishing theo thiết kế: chúng được ràng buộc với nguồn gốc hợp pháp và không liên quan đến bí mật được chia sẻ, vì vậy thông tin xác thực không thể bị thu thập trên một trang web giả mạo, không giống như OTP. Kẻ tấn công làm proxy lưu lượng truy cập đến một tên miền trông giống hệt không thể có được chữ ký hợp lệ cho nguồn gốc của ngân hàng. Liên kết động đóng góp ít hơn trong vector này, nhưng vẫn là bắt buộc để đảm bảo mọi sự phê duyệt là duy nhất cho số tiền và người thụ hưởng dự định. Các biện pháp bổ sung (giáo dục về phishing, tách biệt rõ ràng giữa đăng nhập và phê duyệt thanh toán, chấm điểm rủi ro/bất thường cho các bối cảnh thanh toán bất thường) giúp giảm thiểu rủi ro hơn nữa.

Mối quan ngại: Tấn công phi kỹ thuật / Lừa đảo Ủy quyền Đẩy Thanh toán (APP) Phản hồi: Không có trình xác thực nào có thể ngăn chặn hoàn toàn việc người dùng ủy quyền một khoản thanh toán dưới chiêu bài giả mạo (ví dụ: lừa đảo “tài khoản an toàn”). Liên kết động đảm bảo người dùng thấy rõ người thụ hưởng và số tiền và cung cấp bằng chứng mạnh mẽ về sự đồng ý, nhưng nó không thể thay đổi quyết định của một người thanh toán đã bị thuyết phục. Các biện pháp bù trừ bao gồm cảnh báo theo ngữ cảnh (người thụ hưởng mới, chuyển khoản lớn lần đầu), thời gian chờ hoặc thực hiện chậm đối với những người thụ hưởng có rủi ro cao, xác minh người thụ hưởng mạnh hơn, và kiểm tra tăng cường (xác nhận thêm) khi có tín hiệu rủi ro. Thông báo sau thanh toán và các kênh tranh chấp nhanh chóng giúp phát hiện và ngăn chặn thiệt hại. Chúng tôi thêm các cảnh báo theo ngữ cảnh thời gian thực (ví dụ: người thụ hưởng mới, chuyển khoản lớn lần đầu), thời gian chờ cho người thụ hưởng rủi ro cao, xác minh người thụ hưởng mạnh hơn và thông báo sau thanh toán (“Bạn đã phê duyệt €X cho Y”) để tăng tốc độ phát hiện và phản ứng.

Mối quan ngại: Malware hoặc thiết bị bị xâm phạm Phản hồi: Khóa riêng là không thể xuất và yêu cầu xác minh người dùng cục bộ cho mỗi chữ ký, vì vậy malware không thể đơn giản lấy cắp thông tin xác thực. Rủi ro thực tế là lừa đảo giao diện người dùng trên một hệ điều hành bị xâm phạm hoàn toàn. Giảm thiểu bằng giao diện người dùng an toàn/đã xác minh (ví dụ: xác nhận được bảo vệ), kiểm tra tính toàn vẹn thiết bị/attestation và chặn các thiết bị có rủi ro cao, và các xác nhận đáng tin cậy như SPC hoặc một phần mở rộng xác nhận khi có sẵn. Nếu các chỉ số xâm phạm xuất hiện (phát hiện lớp phủ, root/jailbreak), hãy sử dụng xác minh lại ngoài băng tần hoặc từ chối thực hiện. Không có phương pháp nào dành cho người tiêu dùng là hoàn hảo trên một thiết bị bị chiếm quyền hoàn toàn, nhưng những biện pháp kiểm soát này thu hẹp đáng kể cửa sổ tấn công.

Mối quan ngại: Man‑in‑the‑browser / chiếm đoạt phiên Phản hồi: Các phần mở rộng độc hại hoặc các tập lệnh được tiêm vào có thể khởi tạo hành động trên nguồn gốc hợp pháp. Passkey ràng buộc với nguồn gốc ngăn chặn phishing chéo trang. Liên kết động đảm bảo các chỉnh sửa ngầm đối với số tiền/người thụ hưởng sẽ thất bại. Chúng tôi tăng cường bảo mật kênh thông qua các biện pháp kiểm soát CSP/chống giả mạo và bằng cách yêu cầu một thử thách mới, dùng một lần cho mỗi lần xác nhận.

Mối quan ngại: Mối đe dọa nội bộ hoặc giả mạo phía máy chủ Phản hồi: Phản hồi xác thực được liên kết duy nhất với số tiền/người thụ hưởng ban đầu, vì vậy bất kỳ sự thay thế nào phía máy chủ đều không qua được xác thực. Duy trì các bản ghi liên kết không thể thay đổi, có bằng chứng chống giả mạo (thử thách, thông tin xác thực, chữ ký, và số tiền/người thụ hưởng đã được chuẩn hóa) để kiểm toán/không thể chối cãi. Áp dụng phân chia nhiệm vụ và các biện pháp kiểm soát bốn mắt đối với các quy trình xử lý thanh toán quan trọng để giảm rủi ro nội bộ.

Mối quan ngại: Thiết bị bị đánh cắp / trộm cắp thông tin xác thực Phản hồi: Chỉ sở hữu thiết bị là không đủ: cần có xác minh người dùng (sinh trắc học/PIN) cho mỗi chữ ký, với giới hạn tốc độ và khóa ở cấp hệ điều hành. Mỗi thanh toán yêu cầu một thử thách mới, dành riêng cho giao dịch; các token phiên chung không thể ủy quyền cho các khoản thanh toán tùy ý. Các biện pháp bổ sung như thu hồi thiết bị từ xa, xác thực tăng cường khi sử dụng thiết bị mới, kiểm tra vận tốc địa lý, và thông báo (“Bạn đã ủy quyền €X cho Y”) càng hạn chế việc lạm dụng.

Tổng thể: passkey giảm đáng kể rủi ro phishing và phát lại; liên kết động vẫn cần thiết để đảm bảo tính toàn vẹn của giao dịch, ràng buộc sự phê duyệt với số tiền/người thụ hưởng, và cung cấp bằng chứng mạnh mẽ về sự đồng ý có hiểu biết trong các kịch bản mối đe dọa còn lại.

Câu hỏi 1: Làm thế nào chúng ta có thể chứng minh rằng người dùng thực sự đã thấy và đồng ý với số tiền và người thụ hưởng khi sử dụng passkey? Phản hồi: Về cơ bản đây là câu hỏi về tính không thể chối cãi. Theo PSD2, liên kết động nhằm đảm bảo người dùng nhận thức được những gì họ đang phê duyệt. Với passkey, bằng chứng chúng tôi lưu giữ là chữ ký mã hóa (mã xác thực) và dữ liệu liên quan (nó được gắn với số tiền/người thụ hưởng nào trên máy chủ của chúng tôi). Theo chính sách, chúng tôi hiển thị chi tiết giao dịch cho người dùng trong ứng dụng hoặc trang web trước khi họ xác thực. Chúng tôi ghi lại màn hình/giao diện đó và việc xác thực passkey thành công sau đó cho giao dịch cụ thể đó. Trong trường hợp có tranh chấp, chúng tôi có thể chỉ ra rằng thiết bị của người dùng đã tạo ra một chữ ký hợp lệ cho một thử thách được liên kết với (ví dụ) “€100 cho ACME Corp.” và hệ thống của chúng tôi sẽ không tiếp tục nếu có bất kỳ chi tiết nào khác biệt. Việc tuân thủ của chúng tôi dựa vào việc ghi nhật ký an toàn: chúng tôi đảm bảo hệ thống của mình chống giả mạo trong việc liên kết phản hồi passkey với dữ liệu giao dịch.

Câu hỏi 2: Điều gì sẽ xảy ra nếu thiết bị hoặc hệ điều hành bị xâm phạm? Malware có thể thao túng giao dịch hoặc quy trình passkey không? Phản hồi: Việc xâm phạm thiết bị là một mối đe dọa nghiêm trọng trong bất kỳ kịch bản ngân hàng số nào. Nếu hệ điều hành độc hại, nó có thể cố gắng đánh lừa người dùng hoặc chiếm quyền các quy trình. Tuy nhiên, ngay cả trong trường hợp xấu nhất này, passkey vẫn duy trì một số biện pháp bảo vệ chính. Khóa riêng không thể bị trích xuất bởi malware. Malware cũng không thể mạo danh người dùng với ngân hàng, vì nó không thể tạo ra chữ ký passkey mà không có sinh trắc học/PIN của người dùng. Điều tồi tệ nhất nó có thể làm là thúc đẩy người dùng xác thực một thứ gì đó dưới chiêu bài giả mạo. Liên kết động giúp ở đây bằng cách yêu cầu kiểm tra tính toàn vẹn: malware không thể âm thầm thay đổi chi tiết giao dịch sau đó – nếu nó làm vậy, chữ ký sẽ không được xác minh. Điểm yếu nhất là hiển thị/giao diện người dùng: một Trojan tinh vi có thể thay đổi những gì người dùng thấy (ví dụ: hiển thị “ACME Corp” trong khi giao dịch ngầm thực sự đang đi đến một người thụ hưởng khác). Điều này không hề đơn giản, đặc biệt nếu ứng dụng ngân hàng sử dụng các framework UI an toàn, nhưng nó có thể xảy ra. Dù vậy, nếu chúng tôi phát hiện dấu hiệu xâm phạm thiết bị (hành vi bất thường, chữ ký malware đã biết, v.v.), chúng tôi sẽ chuyển sang xác minh ngoài băng tần hoặc từ chối giao dịch. Tóm lại: Không có giải pháp nào là 100% nếu thiết bị của người dùng bị kẻ tấn công chiếm quyền hoàn toàn. Passkey + liên kết động giảm đáng kể bề mặt tấn công (kẻ tấn công không thể chỉ làm proxy thông tin xác thực hoặc thay đổi dữ liệu mạng; họ sẽ phải thực hiện một màn lừa đảo người dùng trong thời gian thực). Nếu hệ điều hành bị xâm phạm, liên kết động ít nhất đảm bảo bất kỳ sự không khớp nào giữa những gì nên có và những gì được phê duyệt sẽ bị backend của chúng tôi phát hiện.

Câu hỏi 3: Nếu sinh trắc học được sử dụng để mở khóa passkey, đó được coi là một yếu tố hay hai yếu tố? Chúng ta có tuân thủ quy tắc 2 yếu tố không? Phản hồi: Một mình sinh trắc học không đủ cho SCA – nó chỉ là một yếu tố vốn có. Tuy nhiên, trong một triển khai passkey, sinh trắc học không đơn độc: yếu tố sở hữu thiết bị là yếu tố còn lại. Sinh trắc học của người dùng mở khóa khóa riêng được lưu trữ trên thiết bị. Sở hữu và vốn có là hai loại riêng biệt. Điều này tương tự như cách nhiều ứng dụng ngân hàng đã thỏa mãn SCA: bạn có điện thoại (sở hữu) và bạn sử dụng vân tay hoặc khuôn mặt để mở khóa ứng dụng (vốn có). EBA đã công nhận rõ ràng sự kết hợp giữa ràng buộc thiết bị cộng với sinh trắc học là SCA tuân thủ. Kịch bản passkey chính xác là sự kết hợp đó. Nếu người dùng chọn sử dụng mã PIN thay vì sinh trắc học để mở khóa passkey, thì đó là sở hữu + kiến thức, cũng tuân thủ. Chúng tôi thực thi xác minh người dùng trên tất cả các hoạt động passkey (nghĩa là người dùng phải cung cấp sinh trắc học/PIN mỗi lần), vì vậy không có tình huống nào mà chỉ cần có thiết bị là đủ. Do đó, mỗi lần ủy quyền thanh toán qua passkey là một sự kiện hai yếu tố theo định nghĩa của PSD2.

Câu hỏi 4: Kẻ tấn công có thể tái sử dụng một lần xác thực passkey hoặc bằng cách nào đó bỏ qua liên kết động bằng cách thao túng dữ liệu đang truyền không? Phản hồi: Không. Đây là nơi passkey và liên kết động hoạt động cùng nhau một cách mạnh mẽ. Mỗi lần xác thực WebAuthn tạo ra một chữ ký duy nhất được gắn với thử thách (mà chúng tôi tạo cho mỗi giao dịch) và được giới hạn trong phạm vi tên miền của chúng tôi. Kẻ tấn công không thể phát lại chữ ký đó cho một giao dịch khác. Bản thân chữ ký kết hợp nonce của thử thách và chỉ hợp lệ cho những gì nó được cấp ban đầu. Nếu một kẻ tấn công chặn được giao tiếp mạng, họ không thể thay đổi số tiền hoặc người thụ hưởng mà không làm mất hiệu lực của chữ ký (vì thử thách hoặc bối cảnh giao dịch sẽ không còn khớp nữa). Đây chính là biện pháp bảo vệ MITM mà chúng tôi đã thảo luận. Ngoài ra, chữ ký passkey bao gồm dữ liệu nguồn gốc – chúng sẽ không được xác minh nếu không được gửi đến chính xác nguồn gốc trang web/ứng dụng của chúng tôi, vì vậy phishing hoặc chuyển hướng sẽ không hoạt động. Tóm lại, bất kỳ nỗ lực thao túng nào cũng làm mất hiệu lực của mã xác thực, theo các quy tắc liên kết động. Điều này thực sự an toàn hơn một số quy trình dựa trên OTP hiện tại, nơi người dùng đôi khi phê duyệt một mã chung và có nguy cơ yêu cầu đã bị giả mạo. Với passkey, chúng tôi ràng buộc mã hóa việc xác thực người dùng với phiên/giao dịch cụ thể.

Câu hỏi 5: Có bất kỳ ý kiến pháp lý nào đã biết về WebAuthn/passkey cho SCA không? Chúng ta có chắc chắn các cơ quan quản lý sẽ chấp nhận passkey là tuân thủ không? Phản hồi: Cho đến nay, EBA chưa công bố ý kiến rõ ràng về WebAuthn hoặc thuật ngữ “passkey” trong các Hỏi & Đáp hoặc hướng dẫn của họ. Tuy nhiên, dựa trên các nguyên tắc họ đã đặt ra, passkey rõ ràng phù hợp với các phương pháp được chấp nhận. Ý kiến năm 2019 của EBA về cơ bản đã dự đoán trước các phương pháp tương tự FIDO2: đối với yếu tố sở hữu, họ đã đề cập rõ ràng đến “trao đổi khóa công khai/riêng tư” với việc ràng buộc thiết bị phù hợp làm bằng chứng sở hữu. Một passkey WebAuthn chính xác là như vậy – một cặp khóa công khai/riêng tư, với nửa riêng tư được ràng buộc an toàn với thiết bị. Họ cũng đã công nhận “chữ ký được tạo bởi một thiết bị” là một bằng chứng sở hữu hợp lệ. Vì vậy, mặc dù họ không sử dụng thuật ngữ passkey, phương pháp này đã được bao gồm trong các ví dụ của họ. Chúng tôi cũng đã quan sát thấy rằng các công ty thanh toán lớn ở châu Âu đang tiến tới triển khai passkey (ví dụ: PayPal), điều này cho thấy một mức độ tự tin rằng đây là tuân thủ PSD2. Ví dụ này chứng tỏ rằng passkey đang được chấp nhận như một phần của các quy trình SCA tuân thủ, miễn là liên kết động và các yêu cầu tổng thể được đáp ứng.

Câu hỏi 6: Chúng ta có vẫn cần liên kết động nếu passkey đã chống được phishing không? Phản hồi: Có. Passkey loại bỏ phishing chéo nguồn gốc, nhưng PSD2 vẫn bắt buộc liên kết động cho việc khởi tạo thanh toán từ xa. Liên kết động ràng buộc số tiền và người thụ hưởng cụ thể với kết quả SCA và làm mất hiệu lực bất kỳ thay đổi nào, giải quyết tính toàn vẹn của việc ủy quyền ngoài phishing (ví dụ: thay thế MITM/MITB/TPP).

Giải pháp của Corbado tuân thủ Liên kết động và PSD2. Việc hiển thị cho người thanh toán trước khi xác thực, thử thách dùng một lần ràng buộc với số tiền và người thụ hưởng, xác minh nghiêm ngặt phía máy chủ, và kiểm toán không thể thay đổi cùng nhau thỏa mãn các yêu cầu của RTS Điều 5 về nhận thức của người thanh toán, tính duy nhất/cụ thể, vô hiệu hóa khi có thay đổi, và tính toàn vẹn/bảo mật. Tính độc lập của các yếu tố được bảo toàn thông qua yếu tố sở hữu ràng buộc với thiết bị và UV (sinh trắc học hoặc PIN), phù hợp với hướng dẫn của EBA.

So với các phương pháp OTP/SMS ngày nay, Corbado mang lại kết quả bảo mật và trải nghiệm người dùng tốt hơn đáng kể: khả năng chống lại phishing và phát lại, ngăn chặn việc giả mạo tham số một cách âm thầm, bằng chứng không thể chối cãi mạnh mẽ hơn, và giảm ma sát thông qua UV trên thiết bị. Các rủi ro còn lại (ví dụ: tấn công phi kỹ thuật, thiết bị bị xâm phạm) được giảm thiểu bằng các biện pháp kiểm soát cụ thể và hẹp hơn so với các phương pháp cũ. Đối với web, Corbado có thể áp dụng SPC khi nền tảng hỗ trợ (đáng chú ý là Apple) được phổ biến rộng rãi, bổ sung bằng chứng mã hóa về việc hiển thị mà không thay đổi tư thế tuân thủ cốt lõi.

Tóm lại, việc ủy quyền giao dịch dựa trên passkey của Corbado đáp ứng cả tinh thần và văn bản của liên kết động PSD2 và cải thiện khả năng chống gian lận và khả năng kiểm toán so với các phương pháp cũ, đồng thời duy trì một lộ trình rõ ràng cho các cải tiến trong tương lai (SPC) khi hệ sinh thái trưởng thành.

Trong thực tế, passkey thỏa mãn liên kết động khi chúng ta làm ba điều: chúng ta hiển thị số tiền và người thụ hưởng cho người thanh toán trước khi xác minh người dùng; chúng ta tạo ra một mã xác thực cụ thể cho các chi tiết chính xác đó; và chúng ta làm mất hiệu lực của mã khi có bất kỳ thay đổi nào (RTS Điều 5(1)(a–d)). Điều này phản ánh các nguyên tắc mà các cơ quan quản lý đã chấp nhận cho sinh trắc học cục bộ, với sự tiện lợi bổ sung là passkey là gốc của hệ điều hành và hoạt động trên cả kênh web và ứng dụng mà không cần một ứng dụng bổ sung. Kết hợp với ràng buộc nguồn gốc, chúng không hiển thị các yêu cầu giả mạo — chỉ các lời nhắc hợp pháp từ trang web hoặc ứng dụng gốc mới xuất hiện cho người dùng.