Tấn công kênh kề EUCLEAK nhắm vào dòng YubiKey 5
(ninjalab.io)- Trong bối cảnh secure element được dùng làm nền tảng tin cậy cho xác thực mạnh, EUCLEAK là một cuộc tấn công kênh kề được trình diễn trên YubiKey 5Ci, trích xuất khóa bí mật từ triển khai ECDSA của Infineon
- Lỗ hổng cốt lõi là phép toán nghịch đảo modulo không chạy trong thời gian hằng định trong thư viện mật mã của Infineon; nó đã vượt qua khoảng 80 đợt đánh giá chứng nhận Common Criteria cấp cao nhất trong suốt 14 năm
- Kẻ tấn công cần tiếp cận vật lý secure element, cần một vài phép đo điện từ cục bộ cùng thiết bị đắt tiền, phần mềm tùy chỉnh và năng lực kỹ thuật, nhưng bản thân việc đo chỉ cần vài phút là đủ
- Phạm vi ảnh hưởng gồm YubiKey 5 Series với firmware dưới 5.7 và các vi điều khiển bảo mật chạy thư viện mật mã của Infineon, bao gồm cả TPM
- Trong FIDO, việc trích xuất khóa bí mật ECDSA có thể cho phép nhân bản thiết bị, nhưng xét về mục tiêu chống phishing, dùng sản phẩm bị ảnh hưởng vẫn an toàn hơn so với không dùng
EUCLEAK nhắm vào đâu
- Secure element là một vi điều khiển nhỏ tạo và lưu trữ các giá trị bí mật, đồng thời thực hiện các phép toán mật mã; chúng thường được đánh giá bảo mật ở cấp cao nhất của Common Criteria
- Token phần cứng FIDO là phương tiện xác thực mạnh dùng để đăng nhập dịch vụ web, và giao thức FIDO dùng ECDSA làm primitive mật mã cốt lõi
- YubiKey 5 Series là token phần cứng FIDO được sử dụng rộng rãi, dùng Infineon SLE78 làm secure element
- NinjaLab đã phân tích triển khai ECDSA của Infineon bằng Feitian A22, một nền tảng mở JavaCard tương tự dựa trên Infineon SLE78, và thiết kế một cuộc tấn công thực tế khai thác lỗ hổng kênh kề
- Cuộc tấn công được trình diễn trên YubiKey 5Ci
- Lỗ hổng cũng mở rộng sang các vi điều khiển bảo mật mới hơn là Infineon Optiga Trust M và Infineon Optiga TPM
- Nguyên nhân của lỗ hổng là phép nghịch đảo modulo không chạy trong thời gian hằng định trong thư viện mật mã của Infineon Technologies; nó đã không bị phát hiện trong 14 năm và khoảng 80 đợt đánh giá chứng nhận Common Criteria cấp cao nhất
- Tài liệu kỹ thuật chi tiết có tại Download the Writeup
Sản phẩm bị ảnh hưởng và điều kiện tấn công
- Kẻ tấn công phải tiếp cận vật lý secure element và có thể trích xuất khóa bí mật ECDSA bằng một vài phép đo kênh kề điện từ cục bộ
- Trong giao thức FIDO, điều này cho phép nhân bản thiết bị FIDO
- Cuộc tấn công cần thiết bị đắt tiền, phần mềm tùy chỉnh và năng lực kỹ thuật
- Các sản phẩm bị ảnh hưởng gồm:
- Các phiên bản hiện có của mọi vi điều khiển bảo mật Infineon tích hợp thư viện mật mã Infineon
- Các phiên bản hiện có của Infineon TPM
- Tất cả YubiKey 5 Series với firmware dưới 5.7
- Các vi điều khiển bảo mật này được dùng trong nhiều hệ thống bảo mật phụ thuộc vào ECDSA, như hộ chiếu điện tử, ví phần cứng tiền mã hóa, xe thông minh, nhà thông minh, nhưng hiện chưa xác nhận EUCLEAK có thực sự áp dụng được cho các sản phẩm này hay không
- Feitian A22 JavaCard là sản phẩm cũ được dùng trong nghiên cứu và không còn được bán
- Các sản phẩm dựa trên vi điều khiển bảo mật Infineon hiện bán trên webstore của Feitian sử dụng thư viện mật mã riêng của Feitian và, theo hiểu biết của NinjaLab, không bị ảnh hưởng bởi nghiên cứu này
Biện pháp giảm thiểu và thông tin chính thức
- Firmware YubiKey 5.7 đã chuyển từ thư viện mật mã Infineon sang thư viện mật mã mới của Yubico trong bản cập nhật ngày 6/5/2024
- Theo hiểu biết của NinjaLab, thư viện mới này không bị ảnh hưởng bởi EUCLEAK
- Infineon đã có bản vá cho thư viện mật mã, nhưng theo hiểu biết của NinjaLab, bản vá này chưa vượt qua đánh giá chứng nhận Common Criteria
- Yêu cầu CVE đã bị từ chối, và MITRE sử dụng CVE-2024-45678 thay vào đó
- Yêu cầu cập nhật mô tả đang chờ xử lý
- Lập trường chính thức có thể được xem trong các tài liệu sau
- Ngày 3/9/2024: Yubico Security Advisory
- Ngày 9/9/2024: Thông cáo báo chí của BSI (German) / (Google Translated Version)
1 bình luận
Các ý kiến trên Hacker News
Theo bài viết của Ars Technica, kẻ tấn công không chỉ cần tên người dùng và mật khẩu mà còn cần truy cập vật lý vào khóa; sau khi tháo thiết bị ra, nếu muốn trả lại thì còn phải lắp lại, nên đây tuyệt đối không phải là một cuộc tấn công đơn giản
Có lẽ có thể bôi một chút sơn móng tay lên các mối nối nhựa để dùng như một “chim hoàng yến” báo hiệu việc bị can thiệp
Tuy vậy, điểm yếu của token FIDO cũng lộ rõ. Bạn phải tự quản lý danh sách đã đăng ký ở đâu, và nếu token bị mất hoặc bị đánh cắp thì phải tự thu hồi ở tất cả những nơi đã đăng ký
Theo NinjaLab, mọi vi điều khiển bảo mật Infineon chạy thư viện mật mã Infineon đều dễ bị tấn công kiểu này ở tất cả các phiên bản hiện có đã biết
Bao gồm chip hộ chiếu điện tử của Mỹ, Trung Quốc, Ấn Độ, Brazil cùng nhiều nước châu Âu và châu Á; vùng bảo mật trên điện thoại Samsung và OnePlus; ví phần cứng tiền mã hóa như Ledger và Trezor; thẻ SIM; TPM trong laptop Lenovo, Dell, HP; và chip EMV trên thẻ tín dụng/ghi nợ
Nhờ vậy nếu khóa bị mất, bị đánh cắp hoặc hỏng, tôi có thể nhanh chóng trích ra danh sách các trang cần gỡ bỏ
Tôi luôn đăng ký 2 khóa và cất giữ tách biệt về mặt vật lý, để nếu mất một cái thì vẫn đăng nhập được
Không chỉ để truy cập tài sản tiền mã hóa, mà còn trong những bối cảnh nghiêm trọng hơn như các nhà thầu quốc phòng
Trong các trường hợp như vậy, kẻ tấn công có nhiều tài nguyên và động cơ mạnh, và YubiKey được dùng chính là để ngăn những cuộc tấn công như thế
Vì vậy khóa vẫn cung cấp xác thực chống phishing, nhưng phải xem như một số kỳ vọng bảo mật đã bị phá vỡ
Phần khó chịu nhất là không thể đơn giản thay YubiKey
Dù dùng passkey hay khóa không thể phát hiện, trước khi loại bỏ khóa này bạn phải lần lượt vào từng tài khoản và đổi sang khóa mới không bị ảnh hưởng
Việc là khóa không thể phát hiện cũng là vấn đề, vì tôi không nhớ trước đây đã dùng YubiKey ở đâu
Bài Ars [0] cũng nói về PIN, nhưng đó không phải chức năng riêng của YubiKey mà là chức năng của FIDO
[0]: https://arstechnica.com/security/2024/09/yubikeys-are-vulner...
[1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...
Tôi từng thực sự gặp chuyện này khi hải quan Mỹ giữ các thiết bị điện tử, bao gồm cả YubiKey
Sau đó tôi khôi phục được nhiều tài khoản chấp nhận email làm phương thức xác thực hai bước hoặc phương thức xác thực cuối cùng, nhưng một số tài khoản, gồm cả AWS, thì không
Nhiều website khuyến khích đăng ký xác thực hai bước mà không giải thích rõ các phương thức xác thực thay thế và hậu quả của việc mất quyền truy cập
Với các tài khoản đã đăng ký YubiKey, tôi gắn thẻ "YubiKey (FIDO)"
Tuy nhiên trải nghiệm người dùng của toàn bộ luồng này vẫn chưa đạt kỳ vọng
Trong trường hợp của tôi, tôi dùng kèm TOTP lưu trong ứng dụng
Nếu “tất cả YubiKey 5 Series có firmware dưới 5.7 đều bị ảnh hưởng”, tôi cứ nghĩ chỉ cần cập nhật firmware của token phần cứng vật lý là được
Nhưng lại ghi rằng firmware YubiKey không thể nâng cấp
https://support.yubico.com/hc/en-us/articles/360013708760-Yu...
Vậy chắc Yubico sẽ cung cấp thay thế miễn phí chứ? Tôi có vài chiếc YubiKey như vậy…
Nói cách khác, nếu bạn có giá trị đến mức bị nhắm trực tiếp ngoài đời thực thì ngay từ đầu không nên dùng YubiKey
Ai đó có thể tráo khóa dự phòng của bạn, và bạn có thể không nhận ra cho đến khi đã quá muộn
https://support.yubico.com/hc/en-us/articles/15705749884444-...
Trong khi đó chiếc YubiKey 4 của tôi, mới ra mắt chưa đầy hai tháng, đã không còn hoạt động như smartcard PIV chứng thực phần cứng nữa
Việc nói “do phép tính nghịch đảo modular không chạy trong thời gian hằng” không phải là một side-channel tinh vi kiểu phát xạ điện từ rất nhỏ
Việc thời gian có thay đổi theo dữ liệu bí mật hay không gần như là một trong những mục đầu tiên cần kiểm tra khi audit side-channel
Chỉ cần xác minh mọi phép toán luôn dùng cùng số chu kỳ clock bất kể dữ liệu, và lỗi cũng phải xảy ra sau một số chu kỳ clock cố định, không phụ thuộc dữ liệu
Tôi thắc mắc không biết các auditor đã bỏ sót điều này như thế nào
Nếu tôi hiểu đúng bài báo, thứ không hằng thời gian không phải là bản thân việc thực thi thuật toán, mà là duty cycle của side-channel RF có thể quan sát từ bên ngoài
Nếu thời gian thực thi thật sự không hằng, trong trường hợp xấu nhất có lẽ chỉ dùng USB cũng tấn công được, nhưng triển khai của Infineon dường như không dễ bị tấn công thuần về thời gian
Nonce blinding cũng được triển khai, nhưng vấn đề là họ dùng một multiplication mask nhỏ hơn rất nhiều so với kích thước đường cong elliptic, khiến brute-force trở nên khả thi
Dù vậy bản thân cái probe thì rất ngầu
Nếu đã có thể tiếp cận vật lý YubiKey, thì chỉ cần tráo nó bằng một khóa đã mòn tương tự và trông giống là được
Khi đó nạn nhân sẽ tin rằng YubiKey của mình bị hỏng, hoặc kẻ tấn công sẽ có đủ thời gian để dùng YubiKey
Ví dụ tôi có hai YubiKey, nếu ai đó lẻn vào nhà và tráo khóa dự phòng, tôi sẽ không nhận ra cho đến khi cần dùng khóa dự phòng đó
Rốt cuộc, kiểu tấn công này chỉ có ý nghĩa khi mục tiêu đủ giá trị để nhắm trực tiếp, và với mục tiêu như vậy thì có lẽ họ sẽ dùng thứ an toàn hơn YubiKey
ykman list, nên khá dễ đặt ra quy trình kiểm tra xem khóa bị hỏng hay thực sự đã bị tráoNếu yêu cầu bảo mật cao, có thể kiểm tra định kỳ hoặc bảo vệ riêng vị trí vật lý của khóa dự phòng
Tôi cũng tò mò trong số các hardware authenticator thì có thứ gì an toàn hơn YubiKey
Kẻ tấn công có thể nhắm vào thiết bị, chặn liên lạc, hoặc thi hành lệnh khám/xuất trình với dịch vụ lưu trữ dữ liệu, hay âm thầm xâm nhập dịch vụ đó
PDF giải thích EUCLEAK: https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl...
Bài viết blog của Yubico: https://www.yubico.com/support/security-advisories/ysa-2024-...
Nghiên cứu của NinjaLab rất xuất sắc
Điểm đặc biệt thú vị trong khuyến cáo của Yubico là việc clone cục bộ này cũng vô hiệu hóa attestation (chứng thực) [1] của giao thức WebAuthn
Liệu có thể thiết kế giao thức để chống chịu tốt hơn trước kiểu tấn công clone cục bộ này không?
“Kẻ tấn công có thể dùng khóa attestation đã khôi phục để tạo YubiKey giả. Trong trường hợp này, trong quá trình make credential, một câu lệnh attestation FIDO hợp lệ sẽ được tạo ra, cho phép vượt qua cơ chế kiểm soát ưu tiên mô hình authenticator của tổ chức đối với các phiên bản YubiKey bị ảnh hưởng.”
Toàn bộ mô hình bảo mật của secure element nằm ở việc ngăn trích xuất khóa; nếu điều đó trở nên khả thi thì nó chẳng hơn gì lưu khóa trong một file trên máy tính
Tất nhiên, để lấy khóa thì phải mở thiết bị về mặt vật lý, nên miễn là không ai thực sự lấy được khóa của bạn, nó vẫn an toàn hơn việc lưu trên máy tính
Nếu secret attestation đó có thể bị trích xuất bằng cách nào đó, thì không thể ngăn kẻ tấn công tạo một authenticator giả có thể tạo attestation gian lận mà không cần hành xử như thiết bị thật
Về lý thuyết, có thể giảm tác động của việc rò rỉ một secret attestation đơn lẻ bằng cách dùng attestation gián tiếp hoặc khóa attestation duy nhất cho từng authenticator
Tức là thay vì dùng một khóa attestation được chia sẻ bởi hàng trăm nghìn authenticator như YubiKey, làm theo cách đó; nhưng có lẽ nó vẫn chỉ là biện pháp giảm nhẹ mang tính xác suất
Trên website của Yubico nói rằng bản 5.7 trở lên không bị ảnh hưởng
Một bài khác của Yubico [1] cho biết một trong các tính năng của bản phát hành 5.7 là chuyển sang thư viện mật mã riêng của Yubico để thực hiện các phép toán mật mã nền tảng của RSA và ECC
Hy vọng đã có nhiều người xem xét kỹ. Trong thời đại có rất nhiều triển khai công khai lẫn đóng như hiện nay, tôi không rõ vì sao họ lại muốn dùng thư viện mật mã tự viết
[1] https://www.yubico.com/blog/now-available-for-purchase-yubik...
Nếu cả công ty dựa trên mật mã, thì việc thuê đủ nhà mật mã học ứng dụng để tự kiểm soát số phận của mình thực sự là hợp lý
Cũng có thể có lý do khác, và với mã nguồn đóng thì cân nhắc kinh tế cũng rất lớn
Đặc biệt là trong trường hợp chuyển từ triển khai của nhà cung cấp trước đây vốn đóng, có lẽ dưới dạng cung cấp source, sang triển khai nội bộ thì càng có thể như vậy
Infineon lại làm được nữa rồi. 7 năm trước cũng từng có chuyện như thế này: https://en.wikipedia.org/wiki/ROCA_vulnerability
“Infineon đã có bản vá cho thư viện mật mã, nhưng theo những gì được biết thì vẫn chưa vượt qua đánh giá chứng nhận Common Criteria”, tuy nhiên nói thật thì điều này hoàn toàn không quan trọng