Cách hack Firefox để giải quyết vấn đề không hỗ trợ WebUSB
(github.com/ArcaneNibble)- Proof-of-concept này cho thấy một trang web vẫn có thể giao tiếp với một thiết bị USB cụ thể mà không cần WebUSB, bằng cách khiến Raspberry Pi Pico hoạt động như khóa bảo mật U2F và tận dụng hỗ trợ khóa bảo mật sẵn có của trình duyệt
- Pico không thực hiện chức năng bảo mật thực sự, mà giấu dữ liệu tùy ý trong key handle của thông điệp
U2F_AUTHENTICATEvà vùng chữ ký ECDSA để điều khiển LED và đọc trạng thái chânGP22 - U2F key handle được thiết kế như một blob dữ liệu mờ thuộc sở hữu của security dongle; chức năng giúp các dongle giá rẻ xử lý đăng ký từ nhiều website với bộ nhớ hạn chế này bị lạm dụng để che giấu dữ liệu
- Cách này không phải là lỗ hổng cho phép truy cập thiết bị USB tùy ý, và chỉ hoạt động với thiết bị cố ý phá vỡ quy tắc, nhưng vấn đề về mô hình bảo mật USB, nơi thiết bị USB độc hại có thể hành xử như bàn phím hoặc chuột, vẫn tồn tại
- Trọng tâm tranh luận mở rộng vượt ra ngoài việc Firefox có hỗ trợ WebUSB hay không, sang câu hỏi làm thế nào để xây dựng một nền tảng điện toán lành mạnh và hệ sinh thái mà cả nhà phát triển lẫn người dùng đều có thể hiểu và kiểm soát
Demo truy cập thiết bị USB không cần WebUSB
- Đây là một proof-of-concept cho thấy cách một trang web có thể giao tiếp với thiết bị USB mà không vướng các tranh luận chính trị liên quan đến WebUSB hay yêu cầu người dùng đồng ý
- Demo nhanh được chạy bằng cách nạp
u2f-hax.uf2lên phiên bản RP2040 của Raspberry Pi Pico, rồi mởindex.htmltrên localhost hoặc trong một secure context khác - Các nút
On!vàOff!trên trang sẽ bật/tắt LED của Pico - Trạng thái chân
GP22được cập nhật định kỳ trên trang, và có thể kiểm thử bằng cách chập chân đó với pad GND liền kề bằng dây hoặc kim loại
Cách hoạt động: giả dạng khóa bảo mật U2F
- Pico được giả lập như một dongle U2F, tức một khóa bảo mật xác thực hai yếu tố vật lý
- Thay vì thực hiện chức năng bảo mật thật, nó giấu dữ liệu tùy ý trong thông điệp
U2F_AUTHENTICATE- Dữ liệu được đưa vào key handle và vùng chữ ký
- Nếu key handle bắt đầu bằng
0xfeedface, Pico sẽ lập tức xử lý như thể đã xác nhận sự hiện diện của người dùng và trả dữ liệu về
- Từ góc nhìn của trình duyệt, đây là việc sử dụng chức năng sẵn có để tương tác với khóa bảo mật
Vì sao U2F key handle có thể bị lạm dụng
- Key handle của U2F về mặt khái niệm là một blob dữ liệu mờ do security dongle sở hữu
- Luồng thông thường như sau
- Dongle trả về key handle như kết quả đăng ký
- Relying party lưu nguyên giá trị đó
- Khi xác thực, cùng giá trị được truyền lại cho security dongle
- Chức năng này liên quan đến thiết kế cho phép các dongle giá rẻ có bộ nhớ hạn chế xử lý đăng ký với nhiều website
- Dongle lưu một khóa mã hóa master duy nhất bên trong
- Khi có đăng ký mới, nó tạo cặp khóa công khai/khóa riêng và trả về khóa công khai
- Nó trả về giá trị khóa riêng được mã hóa bằng master key dưới dạng key handle
- Khi xác thực, nó giải mã key handle nhận được bằng master key để dùng khóa riêng
- Để không phải chỉ định thuật toán nội bộ, key handle được xem là dữ liệu mờ, và thuộc tính này được dùng để giấu dữ liệu tùy ý
Dữ liệu trả về được đóng gói như chữ ký ECDSA
- Để gửi dữ liệu ngược lại, dữ liệu tùy ý được giấu như một chữ ký ECDSA
- Chữ ký ECDSA là một tuple gồm hai số
(r, s), mỗi số được tính dựa trênn, tức order của base point trên đường cong elliptic - Các số nằm trong phạm vi order của base point secp256r1 được đóng gói bằng ASN.1
- Trong một số trường hợp có thể phân biệt liệu đó có phải chữ ký ECDSA được tính đúng hay không, nhưng các thành phần không phải relying party không có lý do mạnh để thực hiện kiểm tra vượt quá xác thực cơ bản
- Có khác biệt về hành vi giữa các trình duyệt
- Chrome dường như kiểm tra xem các số của chữ ký có nằm trong phạm vi từ
0đếnnhay không - Firefox thậm chí không thực hiện kiểm tra phạm vi đó
- Chrome dường như kiểm tra xem các số của chữ ký có nằm trong phạm vi từ
- Để vượt qua ổn định kiểm tra cơ bản của Chrome, byte đầu tiên của mỗi số được “lãng phí” bằng
0x7f- Nhờ vậy số luôn là số dương và nhỏ hơn
n - Toàn bộ software stack cho đến JavaScript của trình duyệt sẽ truyền nguyên các con số “đủ hợp lệ” này
- Nhờ vậy số luôn là số dương và nhỏ hơn
Có phải lỗ hổng bảo mật không và mô hình bảo mật USB
- Kỹ thuật này không phải là lỗ hổng truy cập thiết bị USB tùy ý
- Nó chỉ hoạt động với thiết bị cố ý phá vỡ quy tắc, về bản chất là một thiết bị được cố ý làm cho dễ bị khai thác
- Tuy vậy, trên hầu hết nền tảng, mô hình bảo mật quanh thiết bị USB nhìn chung vẫn đáng đặt dấu hỏi
- Nếu cắm một thiết bị USB độc hại, nó có thể làm những việc người dùng có thể làm thông qua các thiết bị như bàn phím hoặc chuột
- Không nên kết nối thiết bị lạ tùy tiện với máy tính, điện thoại, v.v.
Đặt vấn đề về nền tảng và hệ sinh thái
- Mục đích của proof-of-concept không chỉ là lý do cá nhân “vì làm được”, mà còn để phơi bày hiện trạng của các nền tảng điện toán
- Từ góc nhìn của nhà sản xuất widget, họ muốn người dùng cuối có thể dùng thiết bị mới dễ dàng nhất có thể
- Trong hệ sinh thái máy tính và widget hiện nay, có sự lệch pha giữa điều người dùng trực giác kỳ vọng là có thể làm và điều thực sự có thể làm
- “Khóa bảo mật” được kỳ vọng trông như một sản phẩm đơn mục đích được đóng gói gọn gàng, nhưng trên thực tế nó có thể chạy mã tùy ý, xuất hiện dưới bất kỳ hình thức nào và thực hiện hành vi tùy ý
- USB Rubber Ducky và O.MG Cable cũng là những ví dụ chạm tới vấn đề này
- Tính “Universal” của USB đi kèm cả ưu điểm lẫn nhược điểm
- Cả con người lẫn máy tính đều không có cách tốt, dễ dàng và ổn định để phân biệt liệu một thiết bị USB đang chống lại lợi ích của người dùng, đang giúp người dùng, hay là kết quả của sức mạnh lớn hơn và hành vi nổi lên
- Web là cách dễ nhất để phân phối phần mềm sẽ chạy trên máy tính của người khác
- Nhà phát triển ít phải học chi tiết của mọi nền tảng đích hơn, nhưng đồng thời cũng ít học hơn về các quy ước và kỳ vọng của từng nền tảng
- Cuộc thảo luận cần vượt ra ngoài “vì sao Firefox không triển khai WebUSB” hay “liệu có bị Chrome bỏ xa hơn không”, để chuyển sang hướng chủ động nuôi dưỡng các nền tảng lành mạnh cho toàn bộ điện toán, bao gồm desktop, laptop, tablet, điện thoại, IoT và smart home
1 bình luận
Ý kiến trên Hacker News
Firefox không hỗ trợ khả năng giao tiếp với các thiết bị USB tùy ý, nhưng Chrome có WebUSB cho việc này
Tuy nhiên Firefox cũng hỗ trợ giao tiếp với khóa bảo mật U2F qua USB
Dự án này là một nỗ lực khiến vi điều khiển giả làm khóa bảo mật U2F, để giao tiếp với vi điều khiển qua USB trong Firefox
Bằng JavaScript Credentials API(https://developer.mozilla.org/en-US/docs/Web/API/Credential_...) và một chút mẹo, nó gửi dữ liệu và nhận phản hồi
Dù vậy vẫn có thể dùng để tạo thiết bị tùy biến mà trang web có thể sử dụng không cần hộp thoại xin đồng ý
Việc tùy biến bàn phím chạy firmware QMK/Via bằng WebUSB gần như là ác mộng
Để trình duyệt giao tiếp với firmware, về cơ bản phải biến một thiết bị
/dev/hidrawthành có thể đọc bởi toàn thế giới, chẳng khác nào mời gọi đủ trò keyloggingCách dùng này rất khó chịu, mà các công cụ tùy biến offline cũng đều dựa trên Electron nên lợi thế không lớn
Cách обход hợp lý nhất là tạo layout bàn phím mong muốn trên website dưới dạng JSON mẫu, tải JSON kết quả về, rồi dùng công cụ flash có quyền sudo để ghi firmware vào bàn phím
Dù vậy, giá mà có cách nào đỡ khó chịu hơn
main()đang chạyBàn phím có lẽ cũng có thể làm tương tự
Tuy nhiên hệ thống tệp nên báo lỗi nếu ghi JSON không hợp lệ, và đặt thuộc tính bảo mật cho hệ thống tệp mô phỏng để chỉ quản trị viên mới ghi được
Không cần sudo, chỉ cần chấp thuận prompt quyền khi tải xuống hoặc sao chép cấu hình mới vào ổ flash ảo
Ít nhất Caps Lock dường như cũng có thể được thiết lập bằng JavaScript, nên về bản chất nó trở thành một bus giao tiếp rộng 1 bit
Với công cụ OS thông thường thì có thể lên tới 3 bit
Cốt lõi của mô hình quyền là họ trình duyệt đứng ra trung gian hóa quyền truy cập phần cứng
Tất nhiên để trình duyệt làm được như vậy thì ngay từ đầu phải cấp quyền truy cập phần cứng cho nó
Nếu bạn không tin trình duyệt làm quản trị viên của tầng trừu tượng hóa phần cứng thì có thể không chấp nhận, nhưng đó là mô hình mà Via kỳ vọng
Tôi không hiểu vì sao chuyện này lại “khó chịu” hơn việc cấp cho trình duyệt quyền truy cập camera, micro hay đọc bộ nhớ
Ngay cả trên Chromebook do công ty quản lý và bị khóa, tôi vẫn có thể vào https://usevia.app để chỉnh bàn phím QMK không vấn đề gì, và tất nhiên trên thiết bị này tôi hoàn toàn không thể đụng vào các node
/devQMK thì hoàn toàn là flash thủ công
Dù thế tôi cũng ngạc nhiên vì việc tùy biến layout, layer và đèn bằng code dễ hơn tưởng tượng, phần lớn nhờ hỗ trợ từ cộng đồng
Không tiện bằng Via, nhưng vẫn có trình chỉnh sửa keymap đồ họa, biên dịch firmware giúp bạn và nhẹ hơn nhiều
Trên bo mạch Keeb.io, trải nghiệm khá tốt
Luồng bình luận này thú vị ở chỗ có cả những người đang dùng WebUSB nói nó tốt đến mức nào, lẫn những người không dùng thì không hiểu vì sao lại cần nó
Cá nhân tôi thấy nó rất tuyệt
Phần lớn tiện ích WebUSB tôi dùng cũng có bản ứng dụng cài trực tiếp, nhưng vì tôi dùng quá hiếm nên bản web dễ hơn nhiều so với việc cài app, cập nhật rồi chạy
Bớt được một ứng dụng phải cài cũng là một lợi điểm
Tôi đã nghĩ nó sẽ được những người đã chán cảnh phải cài app cho mọi món đồ ưa chuộng
Vì vậy đây là con dao hai lưỡi
Tiện lợi và bảo mật không hợp nhau lắm
Nó hữu ích và dễ thật, nhưng cũng quá thuận lợi để phát sinh lỗ hổng
Sự phình to của web phải dừng lại
Trình duyệt không nên trở thành chiếc bồn rửa vạn năng chứa mọi thứ mà bất kỳ ai trong ngành công nghệ muốn nhét vào
Cài đặt ứng dụng native cũng đâu khó đến vậy
Nói chính xác thì đó không phải USB mà là HID, nhưng ý tưởng tương tự
Hơi lệch chủ đề một chút, nhưng phần lớn luồng thảo luận này có vẻ nói về WebUSB nói chung hơn là bài gốc
Tất nhiên bản hack trong bài gốc tự thân nó khá hay
Một mặt tôi thật sự cần WebUSB, nhưng đồng thời tôi cũng thật sự không muốn WebUSB được trao cho người dùng phổ thông
Thực tế là các hộp thoại đồng ý đã không hiệu quả, và mọi người cứ phê duyệt mọi thứ mà không nhận ra
Họ nói “tôi chẳng bấm gì cả”, nhưng rồi bạn lại phải gạt đi 50 thông báo đẩy spam và xóa quyền push của cả chục trang “tin tức”
Thành thật mà nói, tôi phần nào thích mô hình quyền kiểu Internet Explorer
Đó là cách mà để bật một tính năng cụ thể, bạn phải đánh dấu trang đó là “đáng tin cậy”
Nó khó tìm, mất chút thời gian, hơi rối, và trong hộp thoại modal kiểu hệ thống có một biểu tượng cảnh báo lớn trông khá đáng sợ
Nếu muốn dùng các API nguy hiểm như WebUSB, WebBluetooth thì bắt người dùng phải trải qua quy trình đánh dấu trang là “đáng tin cậy”, số người vô tình bật nhầm sẽ ít hơn nhiều
Trải nghiệm người dùng vẫn tốt hơn cài ứng dụng native, lại có thêm sandboxing, nên sự đánh đổi đó có vẻ đáng giá
Người dùng lớn tuổi trung bình hoàn toàn không biết thông báo web là gì
Theo thời gian họ vô tình bật thông báo từ các trang web đáng ngờ, rồi thật sự tin vào các thông báo spam web bay tới điện thoại kiểu “HELLO YOUR PHONE HAS VIRUS DOWNLOAD "CLEANER APP" TO FIX BEFORE PHONE DIE”
Có những người dường như có siêu năng lực làm hỏng đồ
Nếu bạn không biến một việc thành bất khả thi theo đúng nghĩa đen, họ nhất định sẽ tìm ra cách vô tình làm được nó
Họ làm theo hướng dẫn để đổi những thiết lập họ không hiểu, chạy những tính năng họ không hiểu, và cấp những quyền truy cập họ không hiểu
Dù bạn làm quy trình phức tạp đến đâu, gắn bao nhiêu cảnh báo, và cố ngăn sự ngớ ngẩn kiểu này thế nào, chuyện vẫn xảy ra
Vấn đề là cũng có những người biết mình đang làm gì và cố ý sử dụng chúng
Những người đó có thể trân trọng các tính năng mạnh mẽ mà tuyệt đối không nên trao cho kẻ ngốc
Nhưng điều đau đầu là, trên thực tế rất khó tránh khỏi việc khi phơi bày sức mạnh đó ra, nó sẽ tràn ngập những người làm chuyện ngu xuẩn
Một vấn đề lớn là không thật sự hiểu rằng nhiều người dùng hoàn toàn không hiểu mình đang làm gì
Google không hiểu cách thiết kế phần mềm an toàn cho những người như vậy
Các bước rườm rà trông có vẻ vô nghĩa, nhưng thường có mục đích rõ ràng
Đó là xác nhận ý định của người dùng có đủ chắc chắn hay không
Gần đây Apple đã triển khai một số API web sao cho chúng chỉ hoạt động khi website đã được cài đặt, và đây có vẻ là một chiến lược hiểu thiết kế dành cho con người
Nó cho phép truy cập các tính năng PWA hữu ích, nhưng không để trang bất kỳ tùy tiện dùng chúng
Có một bước bổ sung mà người bình thường có thể hiểu được
PWA đã cài đặt luôn hiện trên màn hình chính, nên nó nhắc nhở trực quan về việc đã cấp quyền và là tín hiệu rõ ràng rằng người dùng từng muốn quyền truy cập đó
Nhiều người cần tương tác với thiết bị, nhưng hiện nay trong nhiều trường hợp lựa chọn duy nhất trên thực tế là ứng dụng được cung cấp qua App Store đóng
Nếu muốn phân phối một cách để nhiều người hơn truy cập vào các thiết bị đã ngừng hỗ trợ chính thức, WebUSB là phương án dễ hơn áp đảo
Trong một thế giới khác nơi Chrome không hỗ trợ, người dùng phổ thông có lẽ đã phải cài và chạy [python or other scripting language]
Nếu nhà phát triển thật sự tận tâm, họ có thể phải cung cấp ứng dụng desktop, hoặc đi qua quy trình nộp lên App Store dài dòng và tốn kém
Tôi nghĩ WebUSB có thể có UI an toàn, và tôi cũng khó nghĩ ra thiết bị nào mà người dùng trung bình đang cắm có thể bị xâm phạm
WebUSB hẳn không thể chiếm quyền bàn phím hay chuột (HID), bộ nhớ, Wi-Fi, âm thanh, thẻ thông minh, hay thiết bị U2F
Nhưng nó rất hữu ích cho máy in nhãn độc quyền, đủ loại đồ chơi và thiết bị linh tinh, cũng như việc lập trình và flash vi điều khiển
Nó dễ dùng và tiện, nhưng cũng rất dễ vô tình trao quyền truy cập rất rộng cho bên thứ ba không đáng tin
Như đã nói, việc cấp quyền cho một trang phải là luồng do người dùng chủ động khởi tạo trong bảng quyền
Ứng dụng desktop được sandbox cũng nên như vậy
Nếu một ứng dụng muốn liên tục ghi màn hình, nó phải nhận quyền đó một cách rõ ràng trong bảng điều khiển quyền
Nó không nên được phép bật một hộp thoại modal khiến mọi người chỉ bấm “yes”
Vì trong nhiều trường hợp, mọi người không hiểu về mặt kỹ thuật mình đang được yêu cầu điều gì
USB Serial thật sự rất tuyệt
Cuối cùng cũng chấm dứt được những ứng dụng Electron phiền phức chỉ dùng cho một mục đích
Giờ đã có các công cụ cấu hình thiết bị ngay trong trình duyệt, và điều đó rất tốt
Chỉ cần nhìn ESPHome cùng hàng trăm dự án dựa trên nó, Betaflight, ELRS, Flipper là thấy
Tôi hiểu việc WebKit thiếu hỗ trợ vì do Apple phát triển, và cũng hiểu rằng họ sẽ thận trọng nếu cho phép truy cập thiết bị ngoại vi
Nhưng Firefox thì khác
Firefox thiếu hỗ trợ “kết nối” phần cứng một cách nghiêm trọng và từ lâu đã không thân thiện với nhà phát triển, nên rốt cuộc tôi không dùng nữa
Lý do họ đưa ra cho việc không hỗ trợ là chỉ có sự đồng ý của người dùng thì chưa đủ để truy cập thiết bị, nhưng điều đó vô lý
Ít nhất họ cũng có thể đặt nó sau một cờ dành cho nhà phát triển
Blink đã chứng minh rằng có thể làm nó an toàn
Có vẻ họ cố chấp không vì lý do gì, và không thấy được những trường hợp sử dụng có thể khiến trình duyệt đáng dùng
https://developer.mozilla.org/en-US/docs/Web/API/Serial
https://mozilla.github.io/standards-positions/
Thông tin xác thực U2F lẽ ra phải không thể bị phishing
Vì API U2F của trình duyệt đưa tên miền vào yêu cầu token
Nhưng dùng WebUSB thì một trang web có thể yêu cầu token cho một tên miền tùy ý
Vì U2F và WebUSB đều hiển thị các hộp thoại đồng ý của người dùng trông khá giống nhau, trên thực tế gần như không thể tránh việc một số người dùng bị nhầm lẫn
Khó tin nhưng giải pháp của Google là đưa nhiều thiết bị vào danh sách chặn của WebUSB
Giờ đây các bên làm thiết bị U2F mỗi khi ra sản phẩm mới phải yêu cầu Google thêm vào danh sách chặn
Ai cũng thích việc trình duyệt là một sandbox an toàn cho phép chạy mã không đáng tin cậy, nhưng tôi không hiểu vì sao lại muốn đục nhiều lỗ như vậy vào sandbox đó
[1] https://www.yubico.com/support/security-advisories/ysa-2018-...
[2] https://github.com/WICG/webusb/blob/main/blocklist.txt
Tôi không nghĩ đáng để chấp nhận rủi ro theo dõi bằng vân tay trình duyệt chỉ vì vài chục người dùng cuối khỏi phải tải ứng dụng Electron để tương tác với phần cứng vật lý
Triển khai tính năng rồi khóa sau một nút bật/tắt dành cho nhà phát triển là chuyện điên rồ
Tức là lãng phí hàng trăm giờ phát triển có thể dùng cho việc hữu ích, chỉ để phơi ra một tính năng mà dù sao cũng chẳng ai tìm thấy
Với tư cách nhà phát triển, tôi không ngại để các API chỉ dành cho Chrome kiểu này nằm lại trên Chrome
Dù sao cũng phải để sẵn một trình duyệt Chromium phòng khi có website nào đó thực sự bị hỏng trên Firefox, nên khi làm việc với Web USB thì dùng nó là được
Đây là một bản trình diễn kỹ thuật thú vị, nhưng không phải việc trình duyệt nên làm
Việc không ai thêm chức năng WebUSB bằng tiện ích mở rộng Firefox dường như cũng cho thấy ngay cả với những người dùng tính năng này, nó cũng không đáng để bỏ thời gian phát triển
Các vấn đề về quyền riêng tư và bảo mật đã được nêu ra
Web Serial không phải là tiêu chuẩn web, và không thể trở thành tiêu chuẩn cho đến khi Mozilla hoặc Apple cho rằng các vấn đề này đã được giải quyết
Google không thể một mình biến nó thành tiêu chuẩn web; tiêu chuẩn cần có sự đồng thuận
Thảo luận của Mozilla ở đây: https://github.com/mozilla/standards-positions/issues/336
Thảo luận của WebKit ở đây: https://github.com/WebKit/standards-positions/issues/199
Tôi khó hình dung việc bỏ Firefox để duyệt web chỉ vì webusb
Nó phải là phần mềm có thể tải xuống và không phụ thuộc vào máy chủ bên ngoài
Tuy nhiên, nếu ngay từ đầu thiết bị đã phụ thuộc vào máy chủ của công ty đó để hoạt động, thì việc không phải tải và tin tưởng phần mềm lại là điều tốt
Việc mã chạy trên trình duyệt không thể dùng cổng USB có khi lại là chuyện tốt
Vì tôi không còn phải mở Windows VM để chạy cập nhật firmware hay công cụ tiện ích của các hãng thiết bị âm thanh có hỗ trợ nó, chẳng hạn như Novation
WebUSB cũng nên cho phép làm điều tương tự với nhiều loại thiết bị hơn, nhưng tất nhiên phải có cơ chế cấp quyền phù hợp
Lợi ích là rõ ràng với những người thường xuyên flash thiết bị
Nhưng người dùng bình thường, tức khoảng 3 tỷ người còn lại, hoàn toàn không quan tâm
Đục lỗ vào sandbox vì họ thì nhẹ nhất cũng là bất cẩn
Giải pháp có thể là một công cụ riêng, thậm chí một trình duyệt riêng, chuyên cho mục đích này
Kiểu như Flash Browser
Nó còn có thể bao gồm các công cụ bổ sung để hỗ trợ việc này
Chẳng hạn danh sách cho phép hoặc danh sách chặn được cấu hình sẵn, bookmark các công cụ flash phổ biến, tài liệu tham khảo
Có thể tạo ra trải nghiệm tốt hơn so với việc cố nhồi WebUSB thô vào trình duyệt
Tôi hiểu những tranh cãi và chỉ trích quanh “tiêu chuẩn” đó, nhưng khi dùng để flash GrapheneOS lên điện thoại Pixel, đó là lần cài OS dễ chịu, dễ dàng và nhanh nhất mà tôi từng làm trên bất kỳ thiết bị nào
Đúng nghĩa là cắm vào, bấm, rồi dùng ngay
Phần nói rằng họ mã hóa khóa riêng bằng khóa “master” rồi trả về khóa riêng đã mã hóa dưới dạng key handle thật đáng ngạc nhiên
Thực ra chắc là nó vẫn hoạt động
Nhưng việc cho kẻ tấn công vô hạn cơ hội để thử giải mã khóa riêng đang có trong tay có vẻ sớm muộn gì cũng phản tác dụng, dù tôi biết gì đâu
Ví dụ, một cách khác là có thể tạo khóa riêng từ key handle bằng dẫn xuất khóa mang tính xác định
Kẻ tấn công cũng có thể brute-force cái này giống như với khóa theo từng site đã mã hóa được lưu trong key handle
Điểm cốt lõi là authenticator phi trạng thái, theo định nghĩa, có tính xác định trên phạm vi toàn cục, tức là xuyên suốt bí mật và các site
Khi có một cặp đầu vào-đầu ra, có thể brute-force bí mật bên trong
Cách giải quyết là làm cho trạng thái nội bộ đó đủ lớn để về mặt tính toán là bất khả thi
Tôi tò mò tranh cãi chính trị liên quan đến WebUSB là gì
Đây là API chỉ dành cho Blink do Google tạo ra, và Mozilla cùng Apple đã từ chối vì lý do quyền riêng tư và bảo mật
Nếu không có hai bản triển khai độc lập thì không thể trở thành tiêu chuẩn web, và Google đã không thuyết phục được bất kỳ ai ngoài Google triển khai nó
Dù vậy, trên nhiều website nó vẫn xuất hiện như thể Firefox và Safari “không hỗ trợ được”
“This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.”
— https://wicg.github.io/webusb/
“WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting”
“We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label.”
— https://github.com/WebKit/standards-positions/issues/68
“Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.”
— https://mozilla.github.io/standards-positions/#webusb
Trình duyệt vốn đã có thể truy cập các thiết bị USB cần thiết thông qua giao diện hệ điều hành thông thường
Bàn phím và chuột là ví dụ hiển nhiên
Tôi không biết website nào lại cần quyền truy cập trực tiếp riêng biệt
Các trường hợp sử dụng trông giống như chỉ là cấp quyền truy cập cho lập trình viên web lười dùng ứng dụng độc lập, hoặc cung cấp thêm một cách để theo dõi người dùng
Cả hai đều không phải thứ tôi muốn tin tưởng
Tôi còn không tin tưởng Google và Mozilla đến mức trao cho họ kiểu truy cập đó, huống hồ là một người lạ ngẫu nhiên tạo ra website
Không phải mọi thứ đều cần truy cập được từ web
Tôi không biết nên vạch ranh giới ở đâu, nhưng với tôi quyền truy cập USB đã vượt qua ranh giới đó
Thường thì những người muốn có tính năng ngay bây giờ sẽ thắng cuộc tranh luận này
Vì các lỗ hổng bảo mật trông như vấn đề giả định cho đến khi chúng bị khai thác ngoài thực tế
Càng như vậy, sự phụ thuộc vào Chrome sẽ ngày càng sâu
Tôi cũng không muốn điều đó