다이제스트 인증 (1) - 다이제스트 인증과 특징

• 기본 인증은 편리하고 유연하지만, 전혀 안전하지 않다.
• 메세지를 위조하지 못하게 보호하려는 어떠한 시도도 하지 않는다.
• 다이제스트 인증은 기본 인증과 호환되는 더 안전한 대체재로서 개발되었다.
• 다이제스트 인증은 널리 쓰이지는 않지만, 그 개념은 보안 트랜잭션을 구현하고자 하는 이들에게 여전히 유용하다.

TL;DR

---

자세히…….

• 다이제스트 인증은 그다지 사용되고 있지 않다.

---

---

기본 인증의 개선한 다이제스트 인증

• 좌우명: 비밀번호를 절대로 네트워크를 통해 평문으로 전송하지 않는다.
• 인증 체결을 가로채서 재현하려는 악의적인 사람들을 차단한다.
• 구현하기에 따라서, 메세지 내용 위조를 막는것도 가능하다.
• 그 외 잘 알려진 형태의 공격을 막는다.

---

• 가장 안전한 프로토콜은 아니다.
  • 공개키 기반 메커니즘과 비교했을 때, 그다지 강력한 인증 매커니즘을 제공하진 않는다.
  • 요청과 응답의 나머지 부분에 대해서는 다른 누군가가 엿보는 것이 가능하다.
• 안전한 HTTP 트랜젝션을 위한 많은 요구사항을 만족하지 못한다.
  그러한 요구사항들에는 전송계층 보안 (TLS)와 보안 HTTP(HTTPS)가 더 적합한 프로토콜이다.
• 다른 인터넷 서비스를 위해 제안된 많은 인기 있는 보안 체계들 보다 더 강력하다

  LDAP, CRAM-MD5

• 언뜻 보면 복잡해서 보안 레벨이 높아보이지만 사실 Hash 알고리즘으로 MD5를 사용하는데,
  이 MD5는 보안 레벨이 낮기 때문에 미정부 보안 인증 규격인 FIPS인증 에서 인증하고 있지 않다.
  • FIPS 인증에서는 최소한 SHA-1,SHA1-244,SHA1-256 이상의 해쉬 알고리즘을 사용하도록 권장하고 있다.

MD5 해쉬의 경우에는 특히나 Dictionary Attack에 취약한데,
Dictionary Attack이란, Hash된 값과 원래 값을 Dictionary (사전) 데이터 베이스로 유지해놓고, Hash 값으로 원본 메시지를 검색하는 방식
(출처: 조대협의 블로그)

---

1. 다이제스트 인증의 특징

• 좌우명: “절대로 비밀번호를 네트워크를 통해 보내지 않는다.”
• 비밀번호를 보내는 대신,
  클라는 비밀번호를 비가역적으로 뒤섞은
  지문 fingerprint 혹은 요약 digest 을 보낸다.
• 클라 서버 둘다 비밀번호를 알고 있으므로,
  서버는 클라가 보낸 요약이 비밀번호에 알맞게 대응하는지 검사할 수 있다.

1.1 단방향 요약

• 요약은 정보 본문의 압축이다. 여기서도 압축의 개념이다.
• 요약은 단방향 함수로 동작한다.
• 일반적으로 입력가능한 무한 가지의 모든 입력값들을
  유한한 범위의 압축으로 변환한다.
• 인기있는 요약 함수 중 하나인 MD5는 임의의 바이트 배열을 원래 길이와 상관없이 128비트 요약으로 변환한다.

  MD5: 메세지 다이제스트 #5의 약어
  SHA 보안 해시 알고리즘: 다른 다이제스트 함수

• 요약함수는 보통 암호 체크섬 cryptographic checksums으로 불린다.
  • 단방향 해시함수이거나 지문함수이다.
  • MD5 해시 생성기

1.2 재전송 방지를 위한 난스 사용 nonce

• 요약을 가로채서 서버로 몇번이고 재전송할 수 있기 때문에 안전하지 않다.
• 재전송 공격을 방지하기 위해 서버는 클라에게 난스라고 불리는
  자주 바뀌는 (대략 1ms마다, 혹은 인증할 때마다) 증표를 건네준다.
• 난스를 비밀번호에 섞으면
  난스가 바뀔 때마다 요약도 바뀌게 만들어준다.
• 저장된 비밀번호 요약은
  특정 난스값에 대해서만 유효하고,
  비밀번호 없이 공격자가 올바른 요약을 계산하는 것은 가능하지 않기 때문이다.
• 다이제스트 인증은 난스를 사용할 것을 요구한다.
  • 난스는 WWW-Authenticate 인증요구에 담겨서 서버에서 클라로 넘겨진다.

---

---

2. 다이제스트 인증 핸드셰이크

• HTTP 다이제스트 인증 프로토콜은 기본 인증에서 사용하는 것과 비슷한 헤더를 사용하는,
  강화된 버전의 인증이다.
• 다이제스트 인증의 3단계 핸드셰이크를 보자

1. 1단계
   • 서버는 난스값을 계산한다.
2. 2단계
   • 서버는 난스를 WWW-Authenticate 인증요구 메세지에 담아,
     서버가 지원하는 알고리즘 목록과 함께 클라에 전송한다.
3. 3단계
   • 클라는 알고리즘을 선택하고, 비밀번호와 그 외 데이터에 대한 요약을 계산한다.
4. 4단계
   • 클라는 Authorization 메세지에 요약을 담아 서버에게 돌려준다.
   • 만약 서버가 인증을 원한다면 난스를 보낼 수 있다.
5. 5단계
   • 서버는 요약, 선택한 알고리즘, 그 외 보조 데이터들을 받고, 클라가 했던 그대로 요약을 계산한다.
   • 서버는 그 다음 자신이 계산한 요약과 네트워크로 전송되어 온 요약이 서로 같은지 확인한다.
   • 만약 클라가 대칭적으로 서버에게 클라 난스를 갖고 인증을 요구했다면,
     클라 요약이 만들어진다.
   • 서버는 클라가 미리 다음번 요약을 올바르게 생성할 수 있도록 다음번 난스를 미리 계산해서 클라에게 넘겨줄 수도 있다.

---

---

3. 요약 계산

• 다이제스트 인증의 핵심은

  1. 공개된 정보,
  2. 비밀 정보,
  3. 시한부 난스

  값을 조합한 단방향 요약이다.

• RFC7616 2617

3.1 요약 알고리즘과 입력 데이터

요약은 다음 3가지 요소로부터 계산된다.
A1, A2 두 조각의 데이터는 요약을 생성하기 위해 H와 KD에 의해 처리됨

1. action: 함수들
   1. 단방향 해시 함수 H(d)
   2. 요약 함수 KD(s,d) // s는 비밀, d는 data
2. core: 데이터
   1. 보안정보 데이터
      • 비밀번호 등 보안 정보를 담고 있는 데이터 덩어리 (A1이라 칭하자)
   2. 요청메세지의 비밀 외의 속성 데이터
      • 요청 메세지의 비밀이 아닌 속성을 담고 있는 데이터 덩어리 (A2이라 칭하자)

보안 관련 데이터 A1

• A1 데이터에는
  사용자 이름 / 비밀번호 / 보호 영역 / 난스가 포함된다.

• “<알고리즘>”인 경우 (예 : “SHA-256”),
  A1은 사용자 이름, 영역, 비밀번호를 콜론으로 연결한 것이다.

  A1 = <사용자>:<영역>:<비밀번호>

• <알고리즘> -sess인 경우 (예 : “SHA-256-sess”),
  A1은 서버의 인증 요청에 제공된 nonce 값과 다음 클라이언트 요청의 cnonce 값을 사용하여 계산됩니다

  A1 = H( unq(username) ":" unq(realm) ":" passwd )
       ":" unq(nonce-prime) ":" unq(cnonce-prime)

메세지 관련 데이터 A2

• A2 데이터에는 메세지 자체의 정보를 나타냄
  URL / 요청메서드 / 메세지 엔터티 본문

• 메서드, 리소스, 메세지의 위조를 방지하기 위해 사용됨

• RFC7616 2617은 선택된 보호 수준 (quality of protection, qop)에 따른
  A2의 두가지 사용법을 정의하고 있다.

  1. HTTP 요청 메서드와 URL만 포함하는 것이다.
     이것은 기본값이기도한 qop=”auth”일 때 사용된다.

     A2 = Method ":" request-uri

  2. 메세지 무결성 검사를 제공하기 위해 메세지 엔터티 본문을 추가하는 것
     qop=”auth-init”일 때 사용된다.

     A2 = Method ":" request-uri ":" H(entity-body)

H와 KD 알고리즘

• 다이제스트 인증은 여러가지 요약 알고리즘을 선택할 수 있도록 지원한다.
• MD5와 MD5-sess, SHA-256 등이 있다.

// 개인적으로 빠른 인지를 위해 자바스크립트 문법 사용
KD = (비밀, 데이터) => H(연결(비밀:데이터)) // 요약 함수
H = (데이터) => MD5(데이터) // 해시함수

요약 알고리즘 전반

RFC7616 2617은 주어진 H, KD, A1, A2로 요약을 계산하는 방법에는,
난스 횟수 집계(nc) 및 대칭 인증의 지원(qop)을 포함한다.

response = <"> < KD ( H(A1), unq(nonce)
                              ":" nc
                              ":" unq(cnonce)
                              ":" unq(qop)
                              ":" H(A2)
                      ) <">

3.2 다이제스트 인증 세션

• 어떤 보호 공간을 위한 WWW-Authenticate 인증요구에 대한 클라 응답은,
  그 보호 공간에 대해 인증 세션을 시작하게 한다.
  • 보호 공간은 접근 중인 서버의 루트(canonial root)와 영역의 결합으로 정의된다.
  • (?) 무슨말이지
• 인증세션은 클라가 보호공간의 다른 서버로부터 또 다른 WWW-Authenticate 인증요구를 받을 때까지 지속된다.
  • 클라는 아래 값들을 기억해야한다.
    사용자 이름, 비밀번호, 난스, 난스 횟수, 인증세션과 관련된 알아보기 힘든 값들
• 난스가 만료되면,
  서버는 포함된 난스 값이 낡은 것일 수 있음을 감수하고,
  오래된 Authorization 헤더 정보를 받아들이는 것을 택할 수 있다.
  아니면 서버는 클라이언트가 다시 요청을 보내도록 새 난스 값과 함께 401 응답을 반환할 수도 있다.
  • 이때 응답 헤더의 WWW-Authenticate에 stale=true로 정의함으로써,
    서버는 클라에게 사용자 이름과 비밀번호를 새로 입력하도록 창을 띄울 필요 없이
    새 난스 값으로 요청을 다시 보내라고 말해줄 수 있다.

3.3 사전 인가 preemptive

• 일반적인 인증에서는, 각 요청은 트랜잭션이 완료되기 전에
  요청/인증 요구 사이클을 필요로 한다.
• 만약 클라가 다음 난스가 무엇이 될지 미리 알고 있어서,
  서버가 물어보기 전에 올바른 Authorization 헤더를 생성할 수 있다면,
  이 요청/인증요구 사이클은 생략할 수 있다.

---

• 브라우저는 흔히 사용자 이름과 비밀번호 들에 대한 클라 측 데이터베이스를 관리한다.

• 사용자가 어떤 사이트에 한번 인증을 하면,
  브라우저는 흔히 그 URL에 대한 다음번 요청 때 올바른 Authorization 헤더를 전송한다.

• 다이제스트 인증에서 사전 인가는 약간 더 복잡한데,
  왜냐하면 난스 기술은 재전송 공격을 저지하기 위한 것이기 때문에다.

• 서버는 임의의 난스를 생성하기 때문에,
  인증요구를 받기 전에는 클라가 무엇이 올바른 Authorization 헤더인지 알 방법이 없다.

• 다이제스트 인증은 여러 안전한 기능을 유지하면서 사전 인가를 할 수 있는 몇 가지 방법을 제안한다.

• 클라가 새 WWW-Authenticate 인증요구를 기다리지 않고 올바른 난스를 취득할 수 있는 방법이 몇가지 있다.

1. 서버가 다음 난스를 Authentication-Info 성공 헤더에 담아서 미리 보낸다.
2. 서버가 짧은 시간 동안 같은 난스를 재사용하는 것을 허용한다.
3. 클라가 서버와 동기화되어 있고 예층 가능한 난스 생성 알고리즘을 사용한다.

---

1. 다음 난스 미리 생성하기

• 서버는 Authentication-Info 성공헤더를 통해 다음 난스 값을 미리 제공할 수 있다.

  Authentication-Info: nextnonce="<난스 값>"

• 주어진 다음 난스로 클라는 Authorization 헤더를 미리 만들어 둘 수 있다.

장/단점

• 장점: 트랜잭션 속도 향상
• 단점:
  • 다음요청 보내기 전에 반드시 다음 난스 값을 받아야하기 때문에
    다중요청을 파이프라이능하는 능력은 실질적으로 쓸모없어진다.(?)
  • 파이프라이닝은 회전지연 latency 회피를 위한 기반 기술이기 때문에 성능상 불이익은 더 커진다.

---

2. 제한된 난스 재사용

• 난스를 제한적으로 재사용하는 것이다.
• 예) 서버는 한 난스를 5번만 사용가능하게한다.
• 예) 서버는 한 난스를 10초간 재사용하도록 허가한다.
• 클라는 난스를 미리 알 수 있으므로, 자유롭게 Authorization 헤더와 함께 요청을 발행하여 파이프라이닝 할 수 있다.
• 난스가 만료되면 서버는 서버에게 401 Unauthorized 인증요구를 보낼 것이다.
  (WWW-Authenticate에 stale=true로 정의)

장/단점

• 단점: 공격자의 재전송 공격이 성공하기 쉬워지므로 보안성이 감소된다.

---

3. 동기화된 난스 생성

• 제 3자가 쉽게 예측할 수 없는 공유된 비밀키에 기반하면서
  클라와 서버가 순차적으로 같은 난스를 생성할 수 있도록
  시간적으로 동기화된 난스 생성 알고리즘을 사용하는 것도 가능하다.

---

---

3.4 nonce 어떻게 사용할까 선택.

• 난스의 내용은 불투명하고 구현 의존적이다.

  // RFC 7616 기준
  BASE64(time-stamp H(time-stamp ":" ETag ":" secret-data))

• 타임스탬프는 서버에서 생성된 시간 혹은 아무것이나 반복 불가능한 값이면 된다.

• ETag는 요청된 엔터티에 대한 ETag 헤더값

• 비밀 데이터는 서버만 알고 있는 데이터

• 서버는 클라 인증 헤더를 받은 뒤,
  위 공식에서 해시 부분을 재계산 해보고 클라 인증 헤더의 난스와 일치하지 않거나 타임스탬프가 오래되었다면, 요청을 거절한다.

  • 이 방법에서 서버는 난스의 유효 기간을 제한할 수 있다.

• 재전송 공격을 방지하기 위해, 어떤 구현은 이전에 사용된 난스나 요약을 받아들이지 않도록 결정할 수 있다.

• 혹은 POST나 PUT 요청을 위해 일회성 난스나 요약을 사용하고
  GET 요청을 위해 타임스탬프를 사용할 수도 있다.

3.5 상호 인증

• 서버가 공유된 비밀 정보에 근거한 올바른 응답 요약을 생성할 수 있도록,
  클라 난스(c난스) 값을 제공함으로써 가능해진다.
• 이후 서버는 이 요약을 Authentication-Info 헤더를 통해 클라에 전달한다.

---

---

4. 보호 수준 향상 Quality of Protection

• qop 필드는 클라와 서버가
  어떤 보호 기법을
  어느 정도 수준으로 사용할 것인지 협상할 수 있게 해준다.

1. 서버는 우선 WWW-Authenticate 헤더에 qop 옵션을 수비표로 구분된 목록 형태로 내보낸다.
2. 클라는 그 옵션들 중 지원할 수 있으면서 동시에 자신의 요구에도 맞는 것을 선택하고
   Authorization 헤더의 qop 필드에 담아 돌려준다.

• 인증을 의미하는 auth 와
  메세지 무결성 보호를 의미하는 auth-init이 있다.

메세지 무결성 보호 auth-init

• 무결성 보호가 적용되었을 때 계산되는 H(엔터티 본문)은, 메세지 본문의 해시가 아닌 엔터티 본문의 해시이다.

---

• HTTP 완벽가이드 책을 보고 이해한 내용을 정리 한 글입니다.

---

참고자료

• API 보안
• RFC7616
• 조대협의 블로그