User Authentication

froajnzd·2024년 12월 16일

Cryptography

real world cryptography

목록 보기

12/12

이 장 요약

사람을 인증하는 것과 데이터를 인증하는 것의 차이점

사용자를 비밀번호나 키로 인증하기 위한 사용자 인증

사용자 장치간 연결을 보호하기 위한 사용자 지원 인증

암호학은 아래 두 개념으로 요약할 수 있음

confidentiality (기밀성)
authentication (인증)

실제 응용 프로그램에서 기밀성은 크게 문제가 되지 않음. 인증이 복잡함

지금까지는 "인증"이라는 단어가 혼란스럽게 쓰였는데,
초반에 인증이 실제로 무엇인지 소개하는 것으로 시작한다.

A recap of authentication

MAC, authentication encryption 같은 암호화 프리미티브에서의 인증
: 여기에서의 authentication은 메시지의 authenticity(integrity)를 말한다.
프로토콜의 한명 이상의 참가자를 인증할 수 있는 TLS, Signal과 같은 암호화 프로토콜에서의 인증
: 여기에서의 authentication은 다른 사람에게 자신이 누구인지 증명하는 것을 의미한다.

Authentication은 진짜. 진실, 유효한 것을 증명하거나 보여주는 과정 혹은 행동을 뜻한다. 즉, 아래처럼 나뉠 수 있다.

message/payload authentication - 메세지가 진짜이며, 생성 이후 수정되지 않았음을 증명
origin/entity/identity authentication - 어떤 실체가 진짜 그임을 증명

User authentication, or the quest to get rid of passwords

= 사용자 인증, 또는 비밀번호 제거로의 여정

user authentication : 기계가 인간을 인증하는 방법

user authentication의 가정

서버는 이미 인증되었으며
사용자는 그것과 안전한 연결을 공유한다

One password to rule them all: Single sign-on (SSO) and password managers

사용자들은 서로 다른 비밀번호를 잘 못만들며, 이 모든 비밀번호를 기억하기는 너무 힘들다. 이 문제를 타개하기 위하여 두 솔루션이 채택되었다.

SSO(Single sign-on) : 사용자가 하나의 서비스 계정을 갖고 있음을 증명하여 다양한 서비스에 연결하도록 하는 것이다. 사용자는 여러 서비스에 연결하기 위해 해당 서비스의 비밀번호만 기억하면 된다.
Password manager : SSO는 다양한ㄴ 서비스가 모두 지원하는 경우에는 편리하지만, 웹 시나리오에서는 확장성이 떨어진다. 이 경우에는 서버보다 클라이언트에서 해결하는 것이 훨씬 좋다. 마스터 비밀번호만 기억하면 모든 비밀번호를 사용할 수 있다.

오늘 날 SSO를 사용하는 두 가지 프로토콜은 다음과 같다

SAML(Security Assertion Markup Language 2.0 : XML 인코딩을 사용하는 프로토콜
OpenID Connect(OIDC) : JSON 인코딩을 사용하는 OAuth 2.0(RFC 6749) 인증 프로토콜의 확장판

SAML은 엔터프라이즈 환경에서 널리 사용되지만, 현재로썬 레거시 프로토콜이다.
OIDC는 웹, 모바일 애플리케이션 어디에서나 볼 수 있다.

OAuth2는 OIDC가 사용하는 프로토콜로, 오용하기 쉽다.

SSO는 사용자가 관리해야 하는 비밀번호를 줄여주는 것뿐이지, 비밀번호를 완전히 제거하지는 않는다.
여전히 사용자는 OIDC provider에 연결하기 위해 비밀번호를 사용해야 한다.

결론: 사용자의 신원 관리를 간소화하는 방법으로 하나의 서비스의 한 개의 계정만으로 여러 서비스를 인증할 수 있는 솔루션

Don't want to see their passwords? Use an asymmetric password-authenticated key exchange

비밀번호를 보고 싶지 않나요? 비대칭 비밀번호 인증 키 교환을 사용해라.

asymmetric(augmented) password-authenticated key exchanges (PAKEs)라 불리는 암호화 프로토콜은 사용자가 자신의 비밀번호를 서버에 전달하지 않아도 된다. (양측이 비밀번호를 알아야 하는 대칭(균현잡힌) PAKEs 프로토콜과 대조됨.

SRP(Secure Remote Password) protocol : 현재 가장 인기있는 비대칭 PAKE. 2000년에 처음 RFC 2944에서 표준화됨. 이후 RFC 5054를 통해 TLS에 통합. 꽤 오래된 프로토콜임

결함 : MITM 공격자가 등록 흐름을 가로채면 공격자는 피해자로 가장해 로그인할 수 있다./타원 곡선에서 인스턴스화할 수 없기에 최신 프로토콜에서 잘 작동하지 않고, TLS 1.3 과도 호환되지 않음

PAKE 선택 프로세스로 선정된 프로토콜

CPace : Haase and Benoît Labrique가 발명한 권장 대칭/균형 PAKE
OPAQUE : Stanislaw Jarecki, Hugo Krawczyk, and Jiayu Xu가 발명한 권장 비대칭/증강 PAKE

OPAQUE는 O가 oblivious를 뜻하는 동음이의어 O-PAKE 에서 이름을 따왔다.
OPRF(oblivious pseudorandom function) 암호화 프리미티브에 의존한다.

OBLIVIOUS PSEUDORANDOM RUNCTIONS(OPRFS, 무의식적 의사 난수 함수)
OPRFs는 3장에서 배운 PRF를 모방한 두 명의 참가자로 구성된 프로토콜이다.

PRF : MAC과 어느정도 비슷하다. key, input을 받아 고정된 길이의 완전히 랜덤한 output을 제공한다

암호학에서 oblivious는 일반적으로 한 당사자가 다른 당사자가 제공한 입력을 알지 못한 채 암호화 작업을 계산하는 프로토콜이다

작동방식

Alice가 input에 대한 PRF를 계산하고 싶음. 그러나 입력이 비밀이었으면 좋겠음. Alice는 랜덤값(blind factor)으로 자신의 input을 가리고 Bob에게 보낸다.
Bob은 비밀 키로 이 블라이드 값으로 OPRF를 실행하지만, output은 여전히 가려져있기에 Bob에게는 쓸모가 없다. Bob은 이 값을 Alice에게 다시 보낸다.
Alice는 이전에 실제 출력을 얻기 위해 사용했던 것과 동일한 블라인드 팩터를 사용해 결과를 블라인드 해재한다.

여기서, Alice는 프로토콜을 검토하고 싶을때마다 다른 블라인드 팩터를 만들어야 한다. 어떤 블라인드 팩터를 사용하더라도 동일한 입력을 사용하는 한 항상 동일한 결과를 얻는다.

다음은 이산 로그 문제 그룹에서 구현된 OPRF 프로토콜의 한 예다.

Alice : input을 그룹 원소 x로 바꾼다.
Alice : random blinding factor r을 생성한다
Alice : $blinded_input = x^r$ 를 계산해 input을 블라인드한다
Alice : blinded_input을 Bob에게 보낸다
Bob : $blinded_output = blinded_input^k (where k=secret key)$ 을 계산한다.
Bob : Alice에게 결과를 돌려보낸다
Alice : $output = blinded_output^{1/r} = x^k (where 1/r = inverse of r)$ 을 계산하여 생성된 결과을 해제할 수 있다.

이걸 이용해 asymmetric PAKE의 핵심을 만든다

The OPAQUE ASYMMETRIC PAKE, HOW DOES IT WORK?
Alice(클라이언트)가 인증된 키 교환을 서버와 하고 싶다.
그리고 Alice는 이미 서버의 공개 키를 알거나 인증할 방법이 있다.

1st IDEA. 공개 키 암호화를 사용하여 앨리스 측 연결을 인증한다. 앨리스가 장기 키 쌍을 소유하고 있고, 서버가 공개 키를 알고있는 경우, Alice는 개인 키를 사용해 서버와 상호 인증된 키 교환을 수행하거나 서버가 제공한 챌린지에 서명할 수 있다.
그러나 비대칭 개인 키는 너무 길어서 Alice는 비밀번호만 기억할 수 있다. 현재 기기에 키 쌍을 저장할 수 있지만, 나중에 다른 기기에서 로그인할 수 있기를 원한다.

2nd IDEA. Alice는 Argon2 같은 비밀번호 기반 키 파생함수(KDF)를 사용해 비밀번호에서 비대칭 개인 키를 얻을 수 있다. Alice의 공개키는 서버에 저장될 수 있다. 데이터베이스 유출 시 데이터베이스 전체에 대해 비밀번호를 테스트하는 사람을 피하고 싶다면, 서버가 각 사용자에게 비밀번호 기반 KDF와 함께 사용해야하는 다른 salt를 제공하도록 할 수 있다.
-> precomputation attack(로그인해서 salt를 받아 다음 오프라인에서 계산해서 찾는 공격)에 취약하다

3rd IDEA. 비대칭 개인 키를 도출하기 위해 Alice의 비밀번호화 함께 OPRF 프로토콜을 사용할 수 있다. 서버가 사용자마다 다른 키를 사용하는 것은 salt를 사용하는 것과 같은 효과를 볼 수 있다. 온라인 쿼리를 수행해야 하기에 오프라인 브루트포스 공격을 방지한다. 온라인 쿼리는 로그인 시도를 막는 방법 등으로 브루트 포스 공격을 막을 수 있기 때문에!
-> 이것은 OPAQUE가 실제 작동하는 방법은 아니다.

정리) 비대칭/증강 PAKE는 서버가 실제 비밀번호를 만나지 않아도 인증할 수 있게 하는 방법이다.

One-time passwords aren't really passwords: Going passwordless with symmetric keys

(일회용 비밀번호는 사실 비밀번호가 아니다! 대칭 키로 비밀번호 사용하지 않기)

OTP 기반 사용자 인증의 아이디어는 다음과 같다. 보안은 일반적으로 닞은 엔트로피의 비밀번호 대신, 16~32 byte의 균일한 랜덤 대칭 키에 대한 지식에서 비롯된다. 이 대칭 키를 사용하면 온디맨드 OTP를 생성할 수 있다.

OTP 기반 인증은 모바일 애플리케이션 또는 보안 키에서 가장 자주 구현된다

HMAC-based one-time password(MOTP) : RFC 4226에서 표준화됨. OTP 알고리즘의 additional data는 카운터이다.
time-based one-time password(TOTP) : RFC 6238에서 표준화됨. OTP 알고리즘의 additional data는 시간이다.

현재는 TOTP를 더 많이 쓴다. MOTP는 카운터를 클라이언트와 서버 모두 저장해야 하기 때문

TOTP 작동 방식

Registering : 서버는 대칭 키를 유저에게 전달한다(아마 QR 코드를 사용해서). 그럼, 유저는 이 keyfmf TOTP 앱에 추가할 수 있다.
Logging in : 유저는 TOTP 앱으로 일회용 비밀번호를 계산할 수 있다. 이 작업은 HMAC(symmetric_key, time)으로 계산될 수 있다. (time: 현재 시간)
a. TOTP 앱은 derived one-time password를 잘라내어 사람이 읽을 수 있는 베이스로 표시한다.
b. 유저는 일회용 비밀번호를 복사하거나 관련 앱에 입력한다.
c. 앱은 사용자 관련 대칭 키를 검색하여 사용자와 동일한 방식으로 일회용 비밀번호를 계산한다. 결과가 수신된 일회용 비밀번호와 일치하면 사용자가 성공적으로 인증된다

그러나 이 흐름은 이상적이지 않다.

서버는 대칭 키를 소유하고 있기에 인증을 위조할 수 있다
one-time password에서 social-engineer할 수 있다

이러한 이유로 인해 대칭 키는 비밀번호를 완벽히 대체하지 못한다.
다음으로, 비대칭 키를 사용해 이러한 단점을 어떻게 해결할 수 있는지 살펴보겠다.

Phishing
phishing(social engineering)은 인간의 취약점을 공격하는 것이다. 애플리케이션이 인증을 위해 일회용 비밀번호를 입력해야 한다면, 공격자가 애플리케이션에 사용자로 로그인을 시도하고, 일회용 비밀번호 요청을 받으면 유효한 비밀번호를 요청하는 전화를 하는 것이다.

Replacing passwords with asymmetric keys

(비대칭 키로 비밀번호를 대체하다)

public key cryptography에 대한 장이다.

서버를 인증할 때 asymmetric key를 사용하는 방법은 다음과 같다.

연결을 인증하기 위해 key exchange안에서 asymmetric key 사용
인증된 서버와 이미 안전한 연결을 한 상태에서 asymmetric key 사용

이 각각에 대해서 살펴보겠다.

Mutual Authentication in Key exchanges
= 키 교환에서의 상호 인증
= 연결을 인증하기 위해 key exchange에서 asymmetric key 사용

TLS서버가 클라이언트에게 인증서를 핸드셰이크의 일부로 사용하는 것을 요청할 수 있다.
서버가 핸드셰이크 중에 클라이언트에게 CertificateRequest 메세지를 보내 인증을 요청할 수 있다.
클라이언트는 이에 응답해 Certificate 메세지에 인증서를 포함해 보낸다.
이후, CertificateVerify 메시지를 통해 서명을 보낸다. 이 서명은 지금까지 전송된 모든 메시지와 수신된 메시지에 대한 서명이고, 키 교환에서 사용된 임시 공개 키도 포함이다.
서버가 클라이언트의 인증서를 인식하고, 클라이언트 서명을 성공적으로 검증하면, 클라이언트는 인증된 것이다.

SSH(Secure Shell) 프로토콜
: 클라이언트가 서버에 알려진 공개 키로 핸드셰이크 일부에 서명한다.

Post-handshake User Authentication with FIDO2
= FIDO2를 이용한 핸드셰이크 후 사용자 인증
= 인증된 서버와 이미 안전한 연결을 한 상태에서 asymmetric key 사용

비대칭 키를 사용한 두 번째 인증 방법=이미 안전한 연결(서버만 인증된 상태)에서 사용자를 인증하는 것
서버는 클라이언트에게 무작위 챌린지를 서명하도록 요청할 수 있다
재전송 공격(replay attack) 방지

Fast IDentity Online 2 (FIDO2)

비대칭 키를 사용하여 사용자를 인증하는 방법을 정의하는 오픈 표준
피싱 공격을 주요 목표로 함. 이를 방지하기 위해 하드웨어 인증기에서만 작동하도록 설계
하드웨어 인증기는 서명 키를 생성하고 저장할 수 있으며, 임의의 챌린지를 서명할 수 있는 물리적 구성 요소

FIDO2는 두 가지 명세로 나뉜다

CTAP (Client to Authenticator Protocol)
- 이동식 인증기(roaming authenticator)와 클라이언트가 서로 통신하는 프로토콜
- 이동식 인증기는 주기기 외부에서 사용되는 하드웨어 인증기
- 클라이언트는 인증 프로토콜의 일부로 인증기에 질의(query)하려는 소프트웨어로, 운영체제, 브라우저 같은 네이티브 애플리케이션 등이 해당
WebAuthn (Web Authentication)
- 웹 브라우저와 웹 애플리케이션이 하드웨어 인증기를 사용해 사용자를 인증할 수 있도록 하는 프로토콜
- 따라서 브라우저에서 구현되어야 하며, 웹 애플리케이션 개발 시 하드웨어 인증기를 통한 사용자 인증을 지원하려면, WebAuthn을 사용해야 함

WebAuthn은 이동식 인증기뿐 아니라 플랫폼 인증기(platform authenticator)도 사용할 수 있다. 플랫폼 인증기는 기기에서 제공하는 내장 인증기이며, 플랫폼마다 구현 방식이 다르다.
대부분 생체 인식(지문/얼굴)으로 보호된다

multi-factor authentication

비밀번호 대신 OTP나 FIDO2를 두 번째 인증 요소로 사용

User-aided authentication: Pairing devices using some human help

= 사용자 지원 인증: 사람의 도움을 받아 장치 페어링

요즘 가장 흔히 접할수 있지만 안전하지 못한 연결에는 인터넷을 거치지 않는 프로토콜인 'Wi-Fi', 'NFC(Near Field Communication)'가 있다.
NFC는 휴대폰이나 은행 카드의 '비접촉식' 결제를 할 때 사용하는 방식이다.
이런 통신 프로토콜을 사용하는 장치는 저전력 전자기기부터 풀 기능의 컴퓨터까지 다양하다.

연결하려는 장치가 키를 표시하는 화면이나 수동으로 키를 입력하는 방법을 제공하지 않을 수 있다. 이것을 '프로비저닝' 장치라고 한다.
사람이 너무 긴 타이핑을 하거나 비교하는 것은 사용자 친화적이지 않기에 대부분의 프로토콜은 보안 관련 문자열을 4자리 또는 6자리의 PIN으로 줄이려 한다.

Proximity - NFC 프로토콜을 사용하는 경우 두 장치 모두 서로 가까이 있어야 한다
Time - 장치 페어링은 시간 제약이 있다. 예로 30초 안에 페어링에 성공 못하면 프로세스를 수동으로 재시작해야 한다.

Pre-shared keys

=사전 공유키

두 기기를 안전하게 연결하려면 서로 믿을 수 있는 방법이 필요하다. 그 방법 중 하나는 공개 키를 사용해 인증하는 것이다. 그러나 여기서 문제가 생긴다

공개 키 교환이 어렵다
- 기기 A에서 만든 공개 키를 기기 B로 보내야 한다
- 예로, 공개 키를 화면에 보여주면 상대가 이를 읽거나, QR 코드를 스캔하거나, 사람이 직접 입력해야 한다.
두 가지 연결 방식이 있다
- 불안전한 연결 : 블루투스, WiFi 같은 연결은 쉽게 해킹당할 수 있다.
- 안전한 연결 : 화면에 표시된 코드를 사용하면 해커는 못건드리지만, 옆에서 누군가 볼 수 있다
결국 사람의 도움이 필요하다
- 기기가 자동으로 모든 걸 해결할 수는 없으므로 사람이 공개 키 교환을 도와주어야 한다.

양쪽 기기가 서로의 공개 키를 설정한 후에는, 9장의 프로토콜을 사용해 상호 인증 키 교환을 수행할 수 있다

가장 안전한 방법은 암호학적 키를 사용하는 것이지만, 사용자 친화적이지는 않다는 것이다.
그러나 현실 세계의 암호학은 타협과 절충이 가득하며, 이러한 이유로 다음 두가지 인증 스키마가 존재하고, 기기 인증에서 가장 널리 사용된다

비밀번호 사용해 상호 인증 키 교환을 초기화
짧은 인증 문자열을 사용해 데이터를 가져오기 어려운 상황에서 도움

Symmetric password-authenticated key exchanges with CPace

CPace: 두 기기가 서로 공통된 비밀번호를 알고있을때, 이를 이용해 안전하게 연결하는 방법이다. 즉, 비대칭키 대신 비밀번호를 사용해 인증하는 방법. 비밀번호는 짧고 입력하기 쉽기에 현실에서 자주 사용된다.

CPace 동작 원리

공통된 비밀번호로 generator를 만든다
- 두 기기는 같은 비밀번호를 바탕으로 특정 값을 만든다
임시 키 교환(Ephmeral Diffie-Hellman)
- 만든 생성기를 기반으로 디피헬만 키교환을 수행해서 안전한 연결을 설정한다
- 두 기기는 최종적으로 공유된 세션 키를 얻는다

왜 안전할까?

공격자가 비밀번호를 모르고 키 교환에 참여할 수 없다
상대방을 사칭하려해도 공개 키와 연관된 개인 키를 알수 없기에 실패한다.
비밀번호뿐아니라, 세션ID, 추가 메타데이터(IP 주소 등)를 사용해 안전하게 만든다

즉, 비밀번호를 사용하지만 보안이 뛰어나고 사용하기 쉽다

Was my key exchange MITM'd? Just check a short authenticated string(SAS)

= 키 교환이 MITM이었나요? 짧은 인증 문자열(SAS)을 확인해 보세요

SAS(Short Authenticated String)

두 기기가 안전하게 연결되었는지 확인하려면 MITM 공격이 일어났는지 알아야 한다. 그러나 일부 기기는 복잡한 키 교환이나 긴 데이터를 표시할 수 없다. 대신 숫자나 간단한 문자열을 사용자에게 보여주고 확인한다. 이 방법을 SAS라 한다
두 기기 사이에 교환된 보안 연결의 요약 값을 숫자나 짧은 문자열로 만들어 보여준다
사용자는 두 기기가 보여주는 숫자가 일치하는지 확인만 하면 된다

SAS의 장점

간단하고 빠름 : 숫자 몇 개만 확인하면 된다
보안 강화: 두 숫자가 일치하면 MITM 공격이 없었다는 것을 확인할 수 있다
다양한 기기에서 사용 가능: 화면이 있거나 소리를 낼 수 있는 기기에서 사용할 수 있다.

SAS 문제 : 공격자가 SAS를 속이려할 수 있다

공개 키를 바꿔치기 한 후, 두 기기가 같은 숫자를 만들도록 공격자가 수많은 키를 시도한다
숫자가 짧기에 (20bit면 약 100만 번 중 1번의 확률), 공격자는 운이 좋으면 성공할 수 있다

▶︎ 해결방법 : 공개 키 commitment
이 문제를 막기 위해 "기기는 공개 키를 미리 약속(commit)"하고 나중에 공개한다

Alice가 자신의 공개 키를 약속(공개하지 않고 미리 고정)한다
Bob이 자신의 공개 키를 보낸 후, Alice가 약속했던 키를 공개한다
덕분에 공격자는 Alice의 키를 보고 키를 조작할 수 없게 된다

SAS가 안전한 이유는? 공격자가 숫자(SAS)를 맞추려면, 운에 맡기는 수밖에 없다

SAS가 20비트라면 성공 확률은 1/1,048,576이다
사용자가 SAS를 확인해야하기 때문에 공격자가 무한정 시도하기 어렵다

요약

SAS는 두 기기가 키 교환 후 짧은 숫자 코드로 안전함을 확인하는 방식이다
중간자 공격(MITM)은 공개 키 바꿔치기로 공격을 시도할 수 있지만, 공개 키 약속(Commitment) 방식을 사용하면 이를 막을 수 있다.
사용자는 두 기기의 숫자(SAS)가 일치하는지 확인하면 된다.
공격자가 성공할 확률은 매우 낮고, 반복 시도도 어렵다.

Summary

user authentication protocol(기계가 사람을 인증하기 위한 프로토콜)은 종종 서버만 인증된 보안 연결을 통해 이루어진다. 이러한 의미에서 one-way authenticated 연결을 mutually authenticated 연결로 업그레이드한다.
user authentication protocol은 비밀번호를 많이 사용한다. 비밀번호는 실용적인 해결책이고, 널리 받아들여졌다. 그러나 열악한 위생, 낮은 엔트로피, 데이터베이스 유출로 인해 문제가 야기되었다.
사용자가 여러 개의 비밀번호를 가지고 다니지 않게 할 두가지 방법
- password manager: 사용자가 사용하는 모든 애플리케이션에 대해 강력한 비밀번호를 생성/관리하는 데 사용
- SSO(Single sign-on) : 사용자가 하나의 계정을 사용해 다른 서비스에 등록하고 로그인할 수 있도록 하는 fedarated protocol
서버가 사용자의 비밀번호 학습/저장하는 것을 막을 수 있는 방법은 asymmetric password-authenticated key exchange(asymmetric PAKE)을 사용하는 것이다. (OPAQUE같은) asymmetric PAKE은 사용자가 비밀번호를 사용해 알려진 서버에 인증할 수 있지만, 실제로 비밀번호를 서버에 공개하진 않는다.
비밀번호를 사용하지 않으려면, 사용자가 one-time password(OTP) 알고리즘을 통해 대칭 키를 사용하거나 FIDO2 같은 표준을 통해 비대칭 키를 사용하면 된다
사용자 지원 인증 프로토콜은 종종 안전하지 않은 연결(WiFi, Bluetooth, NFC)을 통해 이루어지며, 두 장치가 서로 인증하는 데 도움된다. 이 시나리오에서 연결을 확보하기 위해 사용자 지원 프로토콜은 두 참가자가 사용할 수 있는 추가 인증된(기밀은 아님) 채널(ex. 디바이스 스크린)을 가지고 있다고 가정
디바이스의 공개 키를 다른 장치로 내보내면 강력하게 상호 인증된 키교환이 이루어질 수 있다. 이러한 흐름은 사용자 친화적이지 않고, 디바이스 제약(ex. 키를 내보내거나 가져올 방법이 없음)으로 인해 불가능할수도 있다.
CPace와 같은 symmetric PAKE(대칭 비밀번호 인증 키 교환)은 장치에서 비밀번호를 수동으로 입력하기만 하면 사용자가 긴 공개 키를 가져오는 부담을 줄일 수 있다. 예로, 대칭 PAKE는 이미 많은 사람들이 가정용 WiFi에 연결하기 위해 사용한다.
short authenticated string(SAS)을 기반으로 한 프로토콜은 키나 비밀번호를 가져올 수 없지만 키 교환 후 짧은 문자열을 표시할 수 있는 장치에 대한 보안을 제공할 수 있다. 이 짧은 문자열은 인증되지 않은 키 교환이 적극적으로 MITM이 되지 않도록 두 장치 모두에서 동일해야 한다.