WebUSB 미지원 문제 해결을 위한 Firefox 해킹 방법

 (github.com/ArcaneNibble)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 이 proof-of-concept는 WebUSB 없이도 웹페이지가 특정 USB 장치와 통신할 수 있음을 보이며, Raspberry Pi Pico가 U2F 보안 키처럼 동작하도록 만들어 브라우저의 기존 보안 키 지원을 이용함
  • Pico는 실제 보안 기능을 수행하지 않고 U2F_AUTHENTICATE 메시지의 key handle과 ECDSA 서명 영역에 임의 데이터를 숨겨 LED 제어와 GP22 핀 상태 읽기를 구현함
  • U2F key handle은 보안 동글이 소유한 불투명 데이터 블롭으로 설계되어 있으며, 저가형 동글이 제한된 메모리로 여러 사이트 등록을 처리할 수 있게 하는 기능이 데이터 은닉에 악용됨
  • 이 방식은 임의의 USB 장치에 접근하는 취약점은 아니며, 규칙을 의도적으로 깨는 장치에서만 동작하지만 악성 USB 장치가 키보드나 마우스처럼 행동할 수 있는 USB 보안 모델 문제는 여전히 존재함
  • 논점은 Firefox의 WebUSB 지원 여부를 넘어, 개발자와 사용자가 모두 이해하고 통제할 수 있는 건강한 컴퓨팅 플랫폼과 생태계를 어떻게 만들 것인가로 확장됨

WebUSB 없이 USB 장치에 접근하는 데모

  • 웹페이지가 WebUSB와 관련된 정치적 논쟁이나 사용자 동의 요구 없이 USB 장치와 통신할 수 있는 방법을 보이는 proof-of-concept임
  • 빠른 데모는 Raspberry Pi Pico의 RP2040 버전에 u2f-hax.uf2를 올리고, index.html을 localhost 또는 다른 secure context에서 여는 방식으로 실행함
  • 페이지의 On!과 Off! 버튼은 Pico의 LED를 토글함
  • GP22 핀 상태는 페이지에 주기적으로 갱신되며, 인접한 GND 패드와 와이어나 금속으로 쇼트해 테스트할 수 있음

동작 방식: U2F 보안 키처럼 가장하기

  • Pico는 U2F 동글, 즉 물리적 2단계 인증 보안 키처럼 에뮬레이션됨
  • 실제 보안 기능을 수행하는 대신 U2F_AUTHENTICATE 메시지 안에 임의 데이터를 숨김
    • 데이터는 key handle과 서명 영역에 들어감
    • key handle이 0xfeedface로 시작하면 Pico는 즉시 사용자 존재를 확인한 것으로 처리하고 데이터를 반환함
  • 브라우저 입장에서는 보안 키와 상호작용하는 기존 기능을 사용하는 형태가 됨

U2F key handle이 악용될 수 있는 이유

  • U2F의 key handle은 개념적으로 보안 동글이 소유하는 불투명한 데이터 블롭임
  • 일반적인 흐름은 다음과 같음
    • 등록 결과로 동글이 key handle을 반환함
    • relying party가 이를 그대로 저장함
    • 인증 시 같은 값을 다시 보안 동글에 전달함
  • 이 기능은 메모리가 제한된 저가형 동글이 많은 웹사이트 등록을 처리할 수 있게 하는 설계와 연결됨
    • 동글은 내부에 고유한 master 암호화 키를 저장함
    • 새 등록 시 공개키/개인키 쌍을 만들고 공개키를 반환함
    • 개인키를 master 키로 암호화한 값을 key handle로 반환함
    • 인증 시 전달받은 key handle을 master 키로 풀어 개인키를 사용함
  • 내부 알고리듬을 특정하지 않기 위해 key handle이 불투명하게 취급되며, 이 속성이 임의 데이터 은닉에 사용됨

반환 데이터는 ECDSA 서명처럼 포장됨

  • 데이터를 되돌려 보내기 위해 임의 데이터를 ECDSA 서명처럼 숨김
  • ECDSA 서명은 두 숫자 (r, s)의 튜플이며, 각 숫자는 타원곡선 base point의 order인 n을 기준으로 계산됨
  • secp256r1 base point의 order 범위 안에 있는 숫자들이 ASN.1로 포장됨
  • 실제로 제대로 계산된 ECDSA 서명인지 구별할 수 있는 경우도 있지만, relying party가 아닌 구성요소가 기본 유효성 검사 이상을 수행할 강한 이유는 없음
  • 브라우저별 동작 차이가 있음
    • Chrome은 서명 숫자가 0부터 n 범위 안에 있는지 확인하는 것으로 보임
    • Firefox는 그 범위 확인조차 하지 않음
  • Chrome의 기본 검사를 안정적으로 통과하기 위해 각 숫자의 첫 바이트를 0x7f로 낭비함
    • 이렇게 하면 숫자가 항상 양수이고 n보다 작게 됨
    • 브라우저 JavaScript까지의 소프트웨어 스택은 이 “충분히 유효한” 숫자를 그대로 전달함

보안 취약점 여부와 USB 보안 모델

  • 이 기법은 임의의 USB 장치에 접근하는 취약점이 아님
  • 의도적으로 규칙을 깨는 장치에서만 동작하며, 본질적으로 의도적으로 취약하게 만든 장치임
  • 다만 대부분의 플랫폼에서 USB 장치 주변의 보안 모델은 일반적으로 의문스러운 상태임
  • 악성 USB 장치를 연결하면 키보드나 마우스 같은 장치를 통해 사용자가 할 수 있는 일을 수행할 수 있음
  • 임의의 알 수 없는 장치를 컴퓨터나 휴대폰 등에 연결하지 않아야 함

플랫폼과 생태계에 대한 문제 제기

  • proof-of-concept의 목적은 개인적인 “할 수 있어서”를 넘어, 컴퓨팅 플랫폼의 현 상태를 드러내는 데 있음
  • 위젯 제조자 입장에서는 최종 사용자가 새 장치를 가능한 한 고통 없이 사용할 수 있기를 원함
  • 현재 컴퓨터와 위젯 생태계에는 사용자가 직관적으로 가능하다고 기대하는 것과 실제로 가능한 것 사이의 불일치가 존재함
  • “보안 키”는 잘 포장된 단일 목적 제품처럼 보일 것으로 기대되지만, 실제로는 임의 코드를 실행하고 어떤 형태로든 보일 수 있으며 임의 동작도 가능함
  • USB Rubber Ducky와 O.MG Cable도 이 문제를 건드리는 사례임
  • USB의 “Universal”한 성격에는 장점과 단점이 함께 있음
    • 사람과 컴퓨터 모두 USB 장치가 사용자 이익에 반하는지, 사용자를 돕는지, 더 큰 힘과 창발적 행동의 결과인지 쉽고 안정적으로 구분할 좋은 방법이 없음
  • Web은 다른 사람의 컴퓨터에서 실행될 소프트웨어를 전달하는 가장 쉬운 방식임
  • 개발자는 모든 대상 플랫폼의 세부사항을 배울 필요가 줄었지만, 동시에 각 플랫폼의 관습과 기대도 덜 배우게 됨
  • 논의는 “왜 Firefox가 WebUSB를 구현하지 않는가”나 “Chrome에 더 밀릴 것인가”를 넘어, 데스크톱, 노트북, 태블릿, 휴대폰, IoT, 스마트홈을 포함한 컴퓨팅 전반의 건강한 플랫폼을 의도적으로 가꾸는 방향으로 이동해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Firefox는 임의의 USB 장치와 통신하는 기능을 지원하지 않지만, Chrome에는 이를 위한 WebUSB가 있음
    다만 Firefox도 USB를 통한 U2F 보안 키 통신은 지원함
    이 프로젝트는 마이크로컨트롤러가 U2F 보안 키인 척하게 만들어, Firefox에서 USB로 마이크로컨트롤러와 통신하려는 시도임
    JavaScript Credentials API(https://developer.mozilla.org/en-US/docs/Web/API/Credential_...)와 약간의 트릭으로 데이터를 보내고 응답을 받음

    • 이건 임의의 장치 접근용은 아님
      그래도 웹페이지가 동의 프롬프트 없이 사용할 수 있는 커스텀 장치를 만드는 데는 쓸 수 있음
    • 제대로 이해했다면, Firefox는 피하려던 문제에는 취약하면서 WebUSB는 제공하지 않는 셈 아닌가 싶음

  • QMK/Via 펌웨어가 들어간 키보드를 WebUSB로 커스터마이즈하는 건 악몽에 가까움
    브라우저가 펌웨어와 통신하려면 사실상 /dev/hidraw 장치 하나를 전 세계 읽기 가능으로 만들어야 해서, 온갖 키로깅 장난을 부르는 꼴임
    사용 방식이 매우 찝찝하고, 오프라인 커스터마이징 도구도 전부 Electron 기반이라 장점이 크지 않음
    그나마 합리적인 우회법은 웹사이트에서 템플릿 JSON으로 원하는 키보드 배열을 만들고, 결과 JSON을 내려받은 뒤 sudo 권한의 플래싱 도구로 키보드에 펌웨어를 굽는 방식임
    그래도 덜 찝찝한 방법이 있으면 좋겠음

    • 여러 마이크로컨트롤러는 MicroPython과 에뮬레이션된 플래시 드라이브가 미리 들어 있어서, Python 코드를 떨어뜨리면 실행 중인 main()을 바꿀 수 있음
      키보드도 비슷하게 할 수 있을 듯함
      다만 파일 시스템이 잘못된 JSON을 쓰면 오류를 내고, 에뮬레이션된 파일 시스템에 보안 속성을 둬서 관리자만 쓸 수 있게 하면 됨
      sudo가 필요하지 않고, 새 설정을 가상 플래시 드라이브에 다운로드하거나 복사할 때 권한 프롬프트만 승인하면 됨
    • 표준 키보드에는 Caps Lock, Num Lock, 그리고 나머지 하나까지 LED 3개가 있고, 모두 운영체제 쪽에서 설정 가능함
      적어도 Caps Lock은 JavaScript에서도 설정할 수 있는 것 같아서, 사실상 1비트 폭 통신 버스가 됨
      일반 OS 도구라면 3비트까지 가능함
    • 이건 약간 혼동이 있음
      권한 모델의 핵심은 브라우저 제품군이 하드웨어 접근을 중재한다는 것임
      당연히 브라우저가 그렇게 하려면 처음부터 하드웨어 접근 권한을 줘야 함
      하드웨어 추상화 계층의 관리자로 브라우저를 신뢰하지 않는다면 그럴 수 있지만, Via가 기대하는 모델은 그거임
      브라우저에 카메라, 마이크, 저장소 읽기 권한을 주는 것보다 왜 더 “찝찝한지”는 모르겠음
      잠긴 회사 관리 Chromebook에서도 https://usevia.app에 들어가 QMK 키보드를 문제없이 건드릴 수 있고, 당연히 이 기기에서 /dev 노드는 전혀 만질 수 없음
    • Via 지원은 키보드 펌웨어가 그런 즉석 커스터마이징을 허용하는 기능이고, QMK 자체와는 다르다고 알고 있음
      QMK는 전부 수동 플래싱임
      그래도 코드로 배열, 레이어, 조명을 커스터마이즈하는 게 생각보다 쉬워서 놀랐고, 커뮤니티 지원 덕이 큼
    • Via 대신 QMK 쪽 대안을 찾는다면 QMK Configurator와 QMK Toolbox 조합을 추천함
      Via만큼 편하진 않지만, 그래도 그래픽 키맵 편집기가 있고 펌웨어를 컴파일해 주며 훨씬 덜 비대함
      Keeb.io 보드에서는 경험이 좋았음

  • 이 댓글 흐름은 WebUSB를 쓰는 사람들이 얼마나 좋은지 말하는 쪽과, 안 쓰는 사람들이 왜 필요한지 이해하지 못하는 쪽이 섞여 있어서 흥미로움
    개인적으로는 아주 좋았음
    내가 쓰는 WebUSB 유틸리티 대부분은 직접 설치하는 앱으로도 제공되지만, 너무 드물게 써서 앱을 설치하고 업데이트한 뒤 실행하는 과정보다 웹 버전이 훨씬 쉬움
    설치해야 할 앱이 하나 줄어드는 것도 장점임
    모든 물건마다 앱을 설치해야 하는 것에 지친 사람들에게 인기가 있을 줄 알았음

    • 언젠가 그 유용한 앱을 제공하던 사이트가 완전히 사라질 수 있고, 설치형 앱은 지우기 전까지 멀쩡히 남아 있음
      그래서 양날의 검임
    • 웹브라우저에 로컬 자원 접근 권한을 너무 많이 주는 보안 문제가 더 걱정됨
      편의성과 보안은 잘 맞지 않음
    • 예전에 WebUSB로 Android 기기를 플래싱한 적이 있음
      유용하고 쉽긴 하지만, 취약점이 생기기에도 너무 좋음
      웹의 비대화는 멈춰야 함
      브라우저가 기술 업계의 누구든 원하는 모든 것을 담는 만능 싱크대가 되어서는 안 됨
      네이티브 애플리케이션 설치가 그렇게 어려운 일도 아님
    • 예를 들면 배송 라벨을 구매하면서 저울로 실제 물건의 무게를 재는 경우가 있음
      엄밀히는 USB가 아니라 HID지만, 비슷한 아이디어임

  • 약간 주제에서 벗어나지만, 이 흐름 대부분은 원글보다 WebUSB 전반에 관한 이야기처럼 보임
    물론 원글의 해킹 자체는 꽤 멋짐
    한편으로는 WebUSB가 정말 필요하지만, 동시에 일반 사용자에게 WebUSB가 주어지는 건 정말 원하지 않음
    실제로 동의 팝업은 작동하지 않았고, 사람들은 자기도 모르게 뭐든 승인함
    “아무것도 안 눌렀다”고 말하지만, 스팸 푸시 알림 50개를 밀어내고 열댓 개 “뉴스” 사이트의 푸시 권한을 지우게 되는 식임
    솔직히 Internet Explorer식 권한 모델이 어느 정도 마음에 듦
    특정 기능을 켜려면 사이트를 “신뢰함”으로 표시해야 하는 방식임
    찾기 어렵고, 시간이 좀 걸리고, 약간 헷갈리며, 시스템 스타일 모달 팝업에 꽤 무서운 큰 경고 아이콘이 나옴
    WebUSB, WebBluetooth 같은 위험한 API를 쓰려면 사이트를 “신뢰함”으로 표시하는 절차를 거치게 한다면, 실수로 켜는 사람은 훨씬 줄어들 것임
    사용자 경험은 여전히 네이티브 앱 설치보다 낫고, 샌드박싱도 덤으로 얻으니 그 절충은 가치 있어 보임

    • Chrome의 웹 알림도 완전히 쓰레기장임
      평균적인 고령 사용자는 웹 알림이 뭔지 전혀 모름
      시간이 지나며 수상한 웹사이트 알림을 실수로 켜고, 휴대폰에 날아오는 “HELLO YOUR PHONE HAS VIRUS DOWNLOAD "CLEANER APP" TO FIX BEFORE PHONE DIE” 같은 웹 스팸 알림을 진짜로 믿음
    • 이건 영원한 싸움임
      어떤 사람들은 물건을 망치는 초능력이라도 있는 것 같음
      뭔가를 문자 그대로 불가능하게 만들지 않으면, 반드시 실수로 해낼 방법을 찾아냄
      이해하지 못하는 설정을 바꾸는 가이드를 따라 하고, 이해하지 못하는 기능을 실행하고, 이해하지 못하는 접근 권한을 부여함
      절차를 아무리 복잡하게 만들고 경고를 얼마나 붙이고, 이런 어리석음을 막으려 애써도 그렇게 됨
      문제는 자기가 뭘 하는지 알고 의도적으로 쓰는 사람들도 있다는 것임
      그런 사람들은 바보에게는 절대 주면 안 되는 강력한 기능을 고마워할 수 있음
      하지만 그 힘을 노출하면, 멍청한 일을 저지른 사람들로 넘쳐나는 걸 현실적으로 피하기 어렵다는 게 괴로움
    • 동의함
      많은 사용자가 자신이 뭘 하는지 전혀 이해하지 못한다는 점을 제대로 이해하지 못하는 게 큰 문제임
      Google은 그런 사람들에게 안전한 소프트웨어를 설계하는 법을 이해하지 못함
      귀찮은 절차는 무의미해 보이지만, 종종 명확한 목적이 있음
      사용자의 의도가 확고한지 확인하는 것임
      Apple은 최근 몇몇 웹 API를 웹사이트를 설치한 경우에만 동작하게 구현했는데, 사람을 위한 설계를 이해한 전략으로 보임
      유용한 PWA 기능에는 접근할 수 있게 하지만, 아무 사이트나 임의로 쓰게 하지는 않음
      일반 사람이 이해할 수 있는 추가 절차가 있음
      설치된 PWA는 홈 화면에 계속 보이므로, 권한 부여를 눈에 보이게 상기시키고 사용자가 그 접근을 원했다는 명확한 신호가 됨
    • 일반 대중도 접근할 수 있기를 정말 원함
      많은 사람이 기기와 상호작용해야 하는데, 지금은 닫힌 App Store를 통해 제공되는 앱이 사실상 유일한 선택지인 경우가 많음
      공식 지원이 끊긴 기기에 더 많은 사람이 접근할 방법을 배포하려면 WebUSB가 압도적으로 쉬운 방법임
      Chrome이 지원하지 않는 다른 세계라면, 일반 사용자는 [python or other scripting language]를 설치하고 실행할 수 있어야 했을 것임
      개발자가 정말 열심이라면 데스크톱 앱을 제공하거나, App Store 제출이라는 길고 비싼 과정을 거쳐야 했을 수도 있음
      WebUSB에는 안전한 UI를 만들 수 있다고 생각하고, 평균 사용자가 꽂아 둔 장치 중 무엇이 침해될 수 있는지도 잘 떠오르지 않음
      WebUSB로 키보드나 마우스(HID), 저장소, Wi-Fi, 오디오, 스마트카드, U2F 장치를 장악할 수는 없을 것임
      하지만 독점 라벨 프린터, 잡다한 장난감과 기기, 마이크로컨트롤러 프로그래밍과 플래싱에는 매우 유용함
    • 애플리케이션과 웹사이트가 권한을 요청하는 모달 프롬프트는 사용자 경험으로는 최악임
      쓰기 쉽고 편하긴 하지만, 신뢰할 수 없는 제3자에게 매우 넓은 접근 권한을 실수로 주기도 쉬움
      페이지에 권한을 주는 일은 말한 것처럼 권한 패널에서 사용자가 명시적으로 시작하는 흐름이어야 함
      샌드박스된 데스크톱 애플리케이션도 마찬가지임
      어떤 앱이 화면을 계속 녹화하고 싶다면 권한 제어판에서 명시적으로 그 권한을 받아야 함
      사람들이 그냥 “yes”를 누르게 만드는 모달 대화상자를 띄울 수 있어서는 안 됨
      많은 경우 사람들은 자신이 무엇을 요청받는지 기술적으로 이해하지 못하기 때문임

  • USB Serial은 정말 훌륭함
    한 가지 용도로만 쓰이는 귀찮은 Electron 앱들을 드디어 끝내 줌
    이제 브라우저로 장치를 설정하는 도구들이 있고, 아주 좋음
    ESPHome과 이를 기반으로 하는 수백 개 프로젝트, Betaflight, ELRS, Flipper만 봐도 그렇음
    WebKit이 Apple이 개발하니 지원이 부족한 건 이해하고, 주변기기 접근을 허용한다면 조심스러울 것이라는 점도 이해함
    하지만 Firefox는 다름
    Firefox는 하드웨어 “연결” 지원이 심각하게 부족했고 오래전부터 개발자에게 친화적이지 않았기 때문에, 결국 쓰지 않게 됨
    지원하지 않는 이유로 사용자 동의만으로는 장치 접근이 충분하지 않다고 하는데, 그건 말이 안 됨
    개발자 플래그 같은 곳 뒤에라도 둘 수 있었음
    Blink는 안전하게 만들 수 있음을 증명했음
    이유 없이 고집을 부리고, 브라우저를 쓸 만하게 만들 사용 사례를 보지 못하는 것 같음
    https://developer.mozilla.org/en-US/docs/Web/API/Serial
    https://mozilla.github.io/standards-positions/

    • 악성 웹사이트가 WebUSB로 FIDO/U2F 키에 접근한 꽤 큰 보안 문제가 있었음
      U2F 자격 증명은 피싱이 불가능해야 함
      브라우저의 U2F API가 토큰 요청에 도메인 이름을 넣기 때문임
      하지만 WebUSB를 쓰면 사이트가 임의의 도메인 이름에 대한 토큰을 요청할 수 있었음
      U2F와 WebUSB가 둘 다 꽤 비슷해 보이는 사용자 동의 상자를 띄웠기 때문에, 일부 사용자가 헷갈리는 걸 피하기는 사실상 불가능함
      믿기 어렵지만 Google의 해결책은 WebUSB에서 많은 장치를 차단 목록에 넣는 것이었음
      이제 U2F 장치를 만드는 곳은 새 제품을 출시할 때마다 Google에 차단 목록 추가를 요청해야 함
      브라우저가 신뢰할 수 없는 코드를 실행하게 해 주는 안전한 샌드박스라는 점은 모두 좋아하면서, 왜 그 샌드박스에 이렇게 많은 구멍을 뚫고 싶어 하는지는 모르겠음
      [1] https://www.yubico.com/support/security-advisories/ysa-2018-...
      [2] https://github.com/WICG/webusb/blob/main/blocklist.txt
    • 마이크로컨트롤러를 가지고 있는데도 WebUSB나 WebSerial이 필요했던 횟수는 한 손으로 셀 수 있음
      물리 하드웨어와 상호작용하려고 Electron 앱을 받지 않아도 되는 수십 명의 최종 사용자를 위해 지문 추적 위험을 감수할 가치는 없다고 봄
      기능을 구현해 놓고 개발자 토글 뒤에 잠그는 건 미친 짓임
      유용한 일에 쓸 수 있는 수백 시간의 개발 시간을 낭비해서, 어차피 아무도 찾지 못할 기능을 노출하는 셈임
      개발자로서 이런 Chrome 전용 API는 Chrome에만 남아도 상관없음
      어차피 Firefox에서 실제로 깨지는 웹사이트가 있을 때를 대비해 Chromium 브라우저 하나는 대기시켜야 하니, 웹 USB 작업할 때 그걸 쓰면 됨
      멋진 기술 시연이긴 하지만 브라우저가 해야 할 일은 아님
      Firefox 확장으로 WebUSB 기능을 추가한 사람이 없다는 사실도, 이 기능을 쓰는 사람들에게조차 개발 시간을 들일 만큼 가치 있지 않다는 걸 보여주는 듯함
    • 그건 사실이 아님
      개인정보와 보안 문제가 제기되어 왔음
      Web Serial은 웹 표준이 아니고, Mozilla나 Apple이 이 문제들이 해결되었다고 보기 전까지는 표준이 될 수 없음
      Google이 단독으로 웹 표준으로 만들 수는 없고, 표준에는 합의가 필요함
      Mozilla 논의는 여기 있음: https://github.com/mozilla/standards-positions/issues/336
      WebKit 논의는 여기 있음: https://github.com/WebKit/standards-positions/issues/199
    • 하루에 장치를 몇 개나 설정하길래 그러는지 모르겠음
      webusb 때문에 웹 브라우징용으로 Firefox를 버린다는 건 상상이 잘 안 됨
    • 플래싱 사이트를 호스팅하던 회사가 망했다는 이유로 내 물리 하드웨어가 갑자기 프로그래밍 불가능해지는 건 받아들일 수 없음
      내려받을 수 있고 외부 서버에 의존하지 않는 소프트웨어여야 함
      다만 장치가 애초에 그 회사 서버에 의존해 동작한다면, 소프트웨어를 내려받고 신뢰하지 않아도 되는 건 좋음

  • 브라우저 기반 코드에서 USB 포트를 사용할 수 없는 게 오히려 좋은 일일 수도 있음

    • Linux 사용자로서 WebMIDI를 좋아함
      이를 지원하는 오디오 장비 제조사, 예를 들어 Novation의 펌웨어 업데이트나 유틸리티 도구를 실행하려고 더는 Windows VM을 열 필요가 없기 때문임
      WebUSB도 더 많은 종류의 장치에 같은 일을 가능하게 해야 하지만, 당연히 적절한 권한 메커니즘은 있어야 함

  • 장치를 자주 플래싱하는 사람들에게 이점은 명확함
    하지만 평범한 사용자, 즉 나머지 30억 명쯤 되는 사람들은 전혀 신경 쓰지 않음
    그 사람들을 위해 샌드박스에 구멍을 뚫는 건 좋게 봐도 부주의함
    해결책은 이 용도 전용의 별도 도구, 어쩌면 별도 브라우저일 수 있음
    Flash Browser 같은 것임
    이 작업을 돕는 추가 도구까지 포함할 수 있음
    미리 구성된 허용 목록이나 차단 목록, 흔한 플래싱 도구 북마크, 참고 자료를 넣는 식임
    WebUSB를 생짜로 브라우저에 억지로 붙이는 것보다 더 나은 경험을 만들 수 있음

  • 그 “표준”을 둘러싼 논란과 비판은 이해하지만, Pixel 폰에 GrapheneOS를 플래싱하는 데 썼을 때는 어떤 기기에서 해 본 OS 설치 중 가장 쾌적하고 쉽고 빨랐음
    말 그대로 꽂고, 클릭하고, 바로 쓰는 수준이었음

  • “마스터” 키로 개인 키를 암호화하고, 암호화된 개인 키를 키 핸들로 반환한다는 부분이 놀라움
    실제로 작동하긴 하겠음
    공격자에게 손에 든 개인 키를 복호화해 볼 무한한 기회를 주는 건 언젠가 역효과가 날 것 같은데, 내가 뭘 알겠나 싶음

    • 생각해 보면 이건 가능한 모든 무상태 인증기 구현과 정확히 같은 위험임
      예를 들어 다른 방식으로는 키 핸들에서 결정론적 키 파생으로 개인 키를 만들 수 있음
      공격자는 키 핸들에 저장된 암호화된 사이트별 키와 마찬가지로 이것도 무차별 대입할 수 있음
      핵심은 무상태 인증기는 정의상 전역적으로, 즉 비밀과 사이트 전반에서 결정론적이라는 점임
      입력-출력 쌍이 주어지면 내부 비밀을 무차별 대입할 수 있음
      해결책은 그 내부 상태를 충분히 크게 만들어 계산적으로 불가능하게 하는 것임

  • WebUSB와 관련한 정치적 논쟁이 뭔지 궁금함

    • WebUSB는 웹 표준이 아님
      Google이 만든 Blink 전용 API이고, Mozilla와 Apple은 개인정보와 보안 이유로 거부했음
      독립 구현이 두 개 없으면 웹 표준이 될 수 없고, Google은 Google 밖 누구도 구현하도록 설득하지 못했음
      그런데도 여러 웹사이트에서는 Firefox와 Safari가 “지원하지 못하는” 것처럼 등장함
      “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
    • 일반적인 정치적 논쟁은 잘 모르겠지만, 개인적으로는 WebUSB를 원하지 않고 형편없는 아이디어라고 봄
      브라우저는 이미 일반 OS 인터페이스를 통해 필요한 USB 장치에 접근할 수 있음
      키보드와 마우스가 명백한 예임
      어떤 웹사이트가 별도의 직접 접근을 필요로 해야 하는지 모르겠음
      사용 사례라고는 독립 실행 애플리케이션을 쓰기 귀찮아하는 웹 프로그래머에게 접근 권한을 주는 것, 또는 사용자를 추적하는 추가 방법을 제공하는 것처럼 보임
      둘 다 신뢰하고 싶지 않음
      Google과 Mozilla에도 그런 접근을 줄 만큼 신뢰하지 않는데, 웹사이트를 만든 임의의 낯선 사람에게는 더더욱 아님
      모든 것이 웹에서 접근 가능해야 하는 건 아님
      선을 어디에 그어야 할지는 모르겠지만, 나에게 USB 접근은 그 선을 넘음
    • 사용자를 보안 문제에 노출하는 것과 웹에 더 많은 기능을 주는 것 사이의 정치임
      보통은 지금 당장 기능을 원하는 사람들이 이기는 싸움임
      보안 결함은 실제 야생에서 악용되기 전까지는 가상의 문제처럼 보이기 때문임
    • 기본적으로 지문 추적 문제이고, 브라우저가 이 시점에서 더 많은 능력을 가져야 하는지에 대한 문제이기도 함
      그럴수록 Chrome 의존은 점점 더 깊어짐
    • 아마 브라우저가 하드웨어에 접근할 수 있다는 점 때문일 것임
      나도 그건 원하지 않음
답변달기