솔트 챌린지 응답 인증 메커니즘

Salted Challenge Response Authentication Mechanism
이 글은 비밀번호 인증에 관한 것이다. 다른 용도는 Scram(동음이의)을 참조하십시오.

암호학에서, 솔트 챌린지 응답 인증 메커니즘(SCRAM)은 서버에 대한 사용자 인증을 제공하는 현대적인 비밀번호 기반 챌린지-응답 인증 메커니즘의 제품군이다. SASL(Simple Authentication and Security Layer)에 지정돼 있어 SMTP, IMAP(전자우편), XMPP(챗) 등의 서비스에 비밀번호 기반 로그인이 가능하다. XMPP의 경우, 이를 지원하는 것은 필수 사항이다.[1]

동기

앨리스는 밥의 서버에 로그인하기를 원한다. 그녀는 자신이 자신이 자처하는 사람이라는 것을 증명할 필요가 있다. 이 인증 문제를 해결하기 위해 앨리스와 밥은 앨리스가 알고 있는 암호와 밥이 검증하는 방법을 알고 있는 암호를 합의하였다.

이제 앨리스는 암호화되지 않은 밥과의 연결을 통해 분명한 텍스트 형태로 그녀의 비밀번호를 보내 그가 확인할 수 있도록 할 수 있었다. 하지만 그렇게 되면 그 암호를 도청하고 있는 말로리가 접근할 수 있게 될 것이다. 앨리스와 밥은 연결을 암호화하여 우회할 수 있었다. 그러나 앨리스는 그 암호화가 밥에 의해 설정되었는지, 맬로리에 의해 설정되었는지도 모르고, 중간중간 맹공격을 해서 설정되었는지도 모른다. 따라서 앨리스는 CRAM-MD5나 다이제스트-MD5처럼 해시 버전을 대신 보낸다.해시인 만큼 말로리는 암호 자체를 얻지 못한다. 그리고 해시는 도전과 함께 소금에 절이기 때문에 말로리는 하나의 로그인 과정에만 그것을 사용할 수 있었다. 하지만 앨리스는 밥에게 몇 가지 비밀 정보를 주고 싶어하고, 그녀는 그것이 말로리가 아니라 밥인지 확인하고 싶어한다.

이를 해결하기 위해 밥은 자신의 인증서에 서명한 인증기관(CA)에 직접 등록했다. 앨리스는 그 서명 시스템에 전적으로 의존할 수 있었지만, 그것이 약점이 있다는 것을 알고 있다. 밥은 그녀에게 중간 공격이 없다는 추가적인 확신을 주기 위해 암호(또는 그 암호의 소금에 절인 해시)를 알고 있다는 증거를 만들고, 이 증거에 자신의 증명서를 포함시킨다. 이러한 포함을 채널 바인딩이라고 하는데, 하위 암호화 채널이 상위 애플리케이션 채널에 '바운드'되기 때문이다.

앨리스는 밥의 인증을 받고, 밥은 앨리스 인증을 받는다. 종합하면, 그들은 상호 인증을 받는다. 다이제스트-MD5는 이미 상호 인증을 활성화했지만 잘못 구현되는 경우가 많았다.[2]

말로리가 중간에서 맨 인 더 미들 공격을 실행하고 CA 서명을 위조할 때, 그녀는 암호의 해시를 회수할 수 있다. 그러나 앨리스가 맬로리의 암호화 키를 해시에 포함시켜 밥으로부터 로그인 실패가 발생했기 때문에 그녀는 단 한 번의 로그인 세션으로도 앨리스 흉내를 낼 수 없었다. 완전히 투명한 공격을 하기 위해서는 맬로리가 앨리스가 사용하는 암호나 밥의 비밀 암호키를 알아야 할 것이다.

밥은 서버 데이터베이스의 데이터 침해에 대해 들어본 적이 있으며, 그는 그의 사용자들의 비밀번호를 명확한 텍스트로 저장하고 싶지 않다고 결정했다. 그는 CRAM-MD5와 다이제스트-MD5 로그인 계획에 대해 들어본 적이 있지만, 이러한 로그인 방식을 사용자들에게 제공하려면 해시되지 않은, 솔트되지 않은 암호를 약하게 저장해야 한다는 것을 알고 있다. 그는 그 아이디어를 좋아하지 않고, 따라서 그는 일반 텍스트로 비밀번호를 요구하기로 선택했다. 그런 다음, 그는 그것들을 bcrypt, scrypt 또는 PBKDF2와 같은 안전한 해싱 방식으로 해싱하고 원하는 대로 소금에 절일 수 있다. 그러나, 그렇다면 밥과 앨리스는 위에서 설명한 문제들에 여전히 직면하게 될 것이다. 이 문제를 해결하기 위해, 그들은 SCCRAM을 사용한다. SCRAM은 Bob이 PBKDF2를 사용하여 그의 비밀번호를 소금에 절인 형식으로 저장할 수 있다. 로그인하는 동안, 밥은 앨리스에게 그의 소금과 PBKDF2 알고리즘의 반복 횟수를 보내고, 앨리스는 이를 이용하여 밥이 그의 데이터베이스에 가지고 있는 해시 암호를 계산한다. 모두 알고 있는 이 값을 바탕으로 한 SCRAM 기반에서의 모든 추가 계산.

프로토콜 개요

모든 클라이언트와 서버가 SHA-1 해싱 알고리즘을 지원해야 하지만, SCRAM은 CRAM-MD5나 다이제스트-MD5와는 달리 기본 해시함수와 독립적이다.[3] 대신 IANA에 의해 정의된 모든 해시함수를 사용할 수 있다. 동기부여 섹션에서 언급한 바와 같이 SCRAM은 서버에 데이터 누수가 발생했을 때 흉포 공격에 대한 강도를 높이는 PBKDF2 메커니즘을 사용한다. 내버려두다 H 서버가 광고하고 클라이언트가 선택한 알고리즘의 이름으로 주어진 선택된 해시함수다. 예를 들어 'SCRAM-SHA-1'은 해시함수로 SHA-1을 사용한다.

암호 기반 파생 키 또는 소금에 절인 암호

클라이언트는 암호, 소금 및 다음과 같은 여러 계산 반복에서 키 또는 소금에 절인 암호를 추출한다.

SaltedPassword = Hi(password, salt, iteration-count) = PBKDF2(HMAC, password, salt, iteration-count, output length of H).

메시지

RFC 5802는 서버와 클라이언트 사이의 4개의 연속된 메시지 이름:

고객 제일주의
클라이언트 첫 번째 메시지는 GS2 헤더(채널 바인딩 플래그와 승인 정보에 대한 선택적 이름 포함), 원하는 이름으로 구성된다. username, 그리고 임의로 생성된 클라이언트 noce c-nonce.
서버 우선의
서버가 자신의 권한 없이 이 클라이언트에 추가함 s-nonce그리고 서버 첫 번째 메시지에 이 메시지를 추가하며, 이 메시지에는 또한 salt 서버가 사용자의 암호 해시 및 반복 횟수를 솔팅하는 데 사용 iteration-count.
의뢰인-최종
클라이언트가 채널 바인딩이 포함된 클라이언트-최종 메시지, 베이스64로 인코딩된 GS2 헤더와 채널 바인딩 데이터, 클라이언트와 서버의 연결 및 클라이언트 증명을 전송한 후, proof.
서버 파이널
통신은 서버 서명이 포함된 서버 최종 메시지와 함께 종료된다. verifier.

교정쇄

클라이언트와 서버가 서로 동일하다는 것을 증명한다. Auth 변수, 구성 요소:

Auth = client-first-without-header + , + server-first + , + client-final-without-proof (쉼표로 구분)

구체적으로는 다음과 같은 형태를 취한다.

= r=c‑nonce,[extensions,]r=c‑nonce‖s‑nonce,s=salt,i=iteration‑count,[extensions,]c=base64(channel‑flag,[a=authzid],channel‑binding),r=c‑nonce‖s‑nonce[,extensions]

증명서는 다음과 같이 계산된다.

ClientKey = HMAC(SaltedPassword, 'Client Key')
ServerKey = HMAC(SaltedPassword, 'Server Key')
ClientProof = p = ClientKey XOR HMAC(H(ClientKey), Auth)
ServerSignature = v = HMAC(ServerKey, Auth)

XOR 연산이 동일한 길이의 바이트 문자열에 적용되는 경우, H(ClientKey) 의 정상적인 해시인 것이다. ClientKey. 'Client Key' 그리고 'Server Key' 말 그대로의 끈이다.

서버가 컴퓨팅을 통해 클라이언트를 승인할 수 있음 ClientKey 로부터 ClientProof 그리고 나서 비교하는 것 H(ClientKey) 저장된 값과 함께

클라이언트가 컴퓨팅 및 비교를 통해 서버를 인증할 수 있음 ServerSignature 단도직접의

저장된 암호

서버는 사용자 이름만 저장하며, salt, iteration-count, H(ClientKey), ServerKey서버에 임시 액세스 권한이 있음 ClientKey 로 암호화된 클라이언트 증빙으로부터 복구되는 동안 H(ClientKey).

고객은 단지 password.

채널 바인딩

채널 바인딩이라는 용어는 상호 인증을 제공하는 애플리케이션 계층을 하위(대부분 암호화) 계층으로 '바인딩'하여 연결의 끝점이 두 계층에서 동일하도록 하는 중간 공격 방지 전략을 설명한다. 채널 바인딩에는 고유 채널 바인딩과 엔드포인트 채널 바인딩의 두 가지 일반적인 방향이 있다. 첫째는 특정 연결을 사용하고 둘째는 엔드포인트가 동일하다는 것을 보장한다.

여러 채널 바인딩 유형이 있으며, 각 유형에는 채널 바인딩 고유 접두사가 있다.[4] 모든 채널 바인딩 유형은 채널과 엔드포인트를 통해 고유한 정보를 제공하는 채널 바인딩 데이터의 내용을 지정한다. 예를 들어, TLS 서버 엔드 포인트 채널 바인딩의 경우, 서버의 TLS 인증서 입니다.[5]

SCRAM을 애플리케이션 계층으로 하는 채널 바인딩의 예로는 TLS(Transport Layer Security)를 하위 계층으로 하는 경우가 있다. TLS는 통신이 암호화되어 있기 때문에 수동적인 도청으로부터 보호한다. 그러나 클라이언트가 서버를 인증하지 않는 경우(예: 서버의 인증서를 확인하여), 이것은 중간 공격을 방지하지 않는다. 이를 위해 엔드포인트는 서로 정체성을 보장할 필요가 있는데, 이는 SCRAM이 제공할 수 있다.

gs2-cbind-flag SCRAM 변수는 클라이언트가 채널 바인딩을 지원하는지 여부를 지정하거나 서버가 채널 바인딩을 지원하지 않는다고 생각하며, c-bind-input은 채널 바인딩 고유 접두사 및 채널 바인딩 데이터 자체와 함께 gs2-cbind-flag를 포함한다.

SCRAM에서는 채널 바인딩이 선택 사항이며, gs2-cbind-flag 변수는 다운그레이드 공격을 방지한다.

서버가 채널 바인딩을 지원하면 광고된 SCRAM 알고리즘 이름에 문자 시퀀스 '-PLUS'를 추가한다.

힘

  • 강력한 암호 저장소: 올바른 방식으로 구현되면 서버는 암호를 소금에 절인 반복 해시 형식으로 저장할 수 있어 오프라인 공격을 더욱 어렵게 하고 데이터베이스 침해의 영향을 줄일 수 있다.[6]
  • 단순성: SCRAM 구현은 다이제스트-MD5보다 쉽다[7].[8]
  • 국제 상호운용성: RFC는 CRAM-MD5와 달리 UTF-8을 사용자 이름과 암호에 사용하도록 요구한다.[7][9]
  • 암호의 소금에 절이고 해시된 버전만 로그인 과정 전체에 사용되며 서버의 염분이 변하지 않기 때문에 암호를 저장한 클라이언트는 해시 버전을 저장할 수 있고, 공격자에게도 일반 텍스트 암호를 노출시키지 않는다. 이러한 해시 버전은 하나의 서버에 바인딩되어 있어 암호 재사용으로 유용하다.[10]

참조

  1. ^ "RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core".
  2. ^ Kurt Zeilenga (19 May 2010). "SCRAM in LDAP Better Password-based Authentication" (PDF). Retrieved 24 January 2014.
  3. ^ "RFC 5802, section 4".
  4. ^ "RFC 5056 section-7.1".
  5. ^ "RFC 5929 section 4".
  6. ^ "SCRAM: A New Protocol for Password Authentication". 19 May 2010. Retrieved 24 January 2014.
  7. ^ a b Tobias Markmann (2 December 2009). "Scram DIGEST-MD5!". Retrieved 23 January 2014.
  8. ^ "DIGEST-MD5 to historic".
  9. ^ CRAM-MD5에서 역사로의 전환
  10. ^ Tobias Markmann (9 June 2010). "Sleep Tight at Night Knowing That Your Passwords Are Safe".

외부 링크