[WebAuthn API] What's new with sign up and sign in on the web

Google의 What's new with sign up and sign in on the web (Google I/O '18) 영상을 일부 요약한 글입니다.

Deep dive 1: How do authenticators work?

---

• 모든 WebAuthn authenticator는 Public key 암호화 기법을 이용한다.
• There is one-time set-up flow during whicih the user registers an authenticator with an account
  • authenticator가 새로운 public-private key pair를 생성
  • private key는 로컬에 저장되고, authenticator에 의해 extract 될 수 없다.
  • public key는 서버에 전송된다.
• 사용자가 인증을 원하는 경우, private key를 소유하고 있음을 증명해야 한다.
  • 이러한 증명 과정은 challenge-respose-based 프로토콜에 의해 수행된다.

• 웹 서버는 개인 키를 사용하는 authenticator에게 challenge를 전송한다.
  • challenge에 대한 암호 서명을 제공하기 위함
• 서명은 웹 서버에 다시 전송되고, public key와 challenge에 의해 검증된다.
• Releasing the signature is also gated on successful user verification such as a fingerprint scan
  • 지문 정보는 로컬에서 authenticator를 unlock 하기 위해 사용된다.
  • 장치를 벗어나 외부에 따로 저장되거나 하지 않는다.

Deep dive 2: One-time setup

---

• Three important participants in this flow
  1. Authenticator itself
  2. Web application running in the browser
  3. Web server

• 사용자의 디바이스에 지문 등록이 되어 있다고 가정한다.
• 등록 프로세스의 시작점에서, 서버는 challenge를 생성한다.
  • large random number
  • 재사용 공격을 막기 위해 랜덤한 큰 수를 challenge로 이용한다.
  • 등록 프로세스에서만 사용되고, 나중에 버려진다.

• 서버는 challenge를 사용자 계정과 연결지어서 저장하고, 사용자 정보와 함께 브라우저에서 실행되는 웹 앱으로 전송한다.

• Web application은 Web authentication API를 호출
  • WebAuthn는 Credential Management API를 확장한다.
  • 그래서 navigator.credentials를 통해 사용할 수 있다.
• 새로운 public key credential을 생성하기 위해, publicKey 옵션(아래)과 함께 create를 호출한다.
  1. 서버로부터 받은 challenge
  2. 사용자 정보 (that will be displayed on the authenticator if it has display)
  3. 사용하고자 하는 암호 알고리즘

• 방금 제시한 3가지 파라미터 외에도, 브라우저는 calling web application의 신뢰할 수있는 도메인 네임을 추출한다.
• 이후 모든 정보는 authenticator로 전송되고, 사용자의 동의? 인증?을 요청한다.
• 이는 악성 웹 사이트가 API를 사용하여 사용자를 추적 할 수 없도록 한다.

• 사용자의 동의가 이루어지면, authenticator는 새로운 public-private key pair를 생성한다.
• private key는 credential ID, user information, domain name과 함께 내부적으로 저장한다.
• 그리고 API 콜은 public key credential 과 함께 resolved!
  • unique identifier, public key, 챌린지를 통해 만든 signature key, domain name, credential id, 그 외 다른 파라미터...

• Web application은 이러한 값들을 서버로 포워딩 한다.

• 그리고 서명을 검증한다.

• 검증이 완료되면 서버는 credential id 와 public key를 사용자 계정 정보와 함께 저장하고 challenge를 invalidate 한다.
  • challenge는 한 트랜잭션 내에서만 유효하다.

Deep dive 3: Passwordless (re-)authentication

---

• 등록 프로세스 이후 authenticator는 private key 정보를, 서버는 public key 정보를 가진다.
• 인증 과정은 challenge-response based 프로토콜을 통해 수행됨
• private key의 소유권을 증명하기 위해 전자서명을 이용한다.

• 먼저 서버는 새로운 challenge를 생성한다.

• 이후 서버는 credential ID와 challenge를 Web application으로 보냄를 Web application으로 보낸다.

• WebAuthn API를 호출한다.
• 서명을 생성하기 위해, pubKey 정보와 함께 navigator.credentials.get을 호출해야 한다.
  • 서버로부터 받은 challenge
  • 서명을 받고자 하는 credential
  • userVerification → 사용자를 로컬로 확인하도록 요청

• 브라우저는 co-linked web application의 신뢰할 수있는 도메인 네임을 추출한다.
• 모든 정보를 authenticator에게 전송한다.

• authenticator는 해당 credential ID에 대해 저장된 정보를 조회한다.
• calling website의 도메인 네임이 credential이 생성된 시점의 것과 일치하는지 비교한다.
  • 피싱 mitigation 효과 (피싱 사이트로부터 인증 요청이 전송되면, authenticator는 도메인 네임 정보가 다른 것을 감지)

• 실제 웹사이트가 맞다면, authenticator는 지문 인식을 통해 로컬 인증을 수행한다.

• 지문 인식 후 authenticator는 private key를 이용하여 도메인 네임, challenge에 대해 서명을 생성한다.

• 서명은 생성된 후 서버로 보내지고, 해당 API 호출은 resolved!
• 서버에서 challenge와 public key에 대응하는 서명이 맞는지 검증한다.

• 올바른 서명으로 판별이 나면 인증 성공

• 마지막으로 challenge를 invalidate 한다.

• 대규모의 사용자 기반을 다루는 경우, identity management 매커니즘을 금세 교체하긴 어렵다.

• WebAuthn의 장점 중 하나는 이를 한 번에 한 단계씩 적용시킬 수 있다는 점이다.

• 2FA를 위한 U2F API의 drop-in replacement

• 조금의 코드 변화로 민감한 기능을 실행하기 전에 passwordless reauthentication을 하게끔 구현할 수 있다.

  • 핸드폰이나 노트북 등의 디바이스에 내장된 지문 인식기를 통해..

• 사용자가 지문 및 하드웨어 토큰을 사용하여 로그인하는 방식에 익숙해지면, 이를 주요한 로그인 매커니즘으로 채택할 수 있을 것이다.

Summarize

---

• WebAuthn API는 공개키 암호를 통해 웹사이트 내에서 강력한 인증 기반을 마련한다.
• 쉽고 안전한 passwordless 로그인에 대한 새로운 feature와 form-factor를 제공한다.