5. Key distribution & Aggrement, Secure communication

Symmetric Key Aggrement among multiple parties

N 파티가 있다고 가정해보면, N개의 shared key가 필요하게 된다. 크게 2가지 방법으로 key 공유가 가능하다.

• Symmetric
  Central Authority를 이용한다.
  CA는 Trusted Third Party, TTP를 의미한다.
• Asymmetric
  Public Key Infrastructure, PKI를 이용한다.

 

 

Issue of key distribution

다음의 내용에 대해서 확인이 필요하다.

• A는 전송자가 TTP임을 확신
• B는 가짜 A가 없음을 확신
• A는 B의 response가 B의 것임을 확신 
• Lifetime of session key

 

 

Needham-Schroeder Shared-key protocol

TTP의 역할을 최소화하고 A와 B 사이의 key 공유를 하는 방법이다.

• Party : A, B, TTP
• Setup :
  $k_{A, T}$ for A, TTP
  $k_{B, T}$ for B, TTP
• Goal :
  Mutual entity authentication이 목표이다.
  (Key establishment)
  이 과정에서 TTP의 역할은 최소화한다.
  (가령 T는 stateless이다.)
• Method
  A→T : $ID_A$, $ID_B$, $N_1$
              A의 아이디, B의 아이디, 임시값1(random)
  T→A : $Ek_{A,T}[N_1 || ID_B || k_{A,B} || Ek_{B,T}[k_{A,B} || ID_A]]$
              $k_{A,B}$ : A와 B 사이의 session key
  A→B : $Ek_{B,T}[k_{A,B} || A]$
  B→A : $Ek_{A,B}[N_2]$
              $N_2$ : 임시값2
  A→B : $Ek_{A,B}[N_2 - 1]$

 

 

Attacks on Needham-Schroeder

Old session key 탈취에 매우 취약하다. 공격자는 이 값을 reuse해서 fresh처럼 B에게 전송하면, A인척 할 수 있다. 방법은 3번째부터 수행하면 된다.

 

C→B : $Ek_{B,T}[k || A]$

B→C : $Ek_{A, B}[N_B]$

C→B : $Ek_{A, B}[N_B -1]$

 

B의 입장에서는 A와 대화하고 있는 것처럼 느끼게 된다. 이를 방지하기 위해서 N은 random으로 생성한다. 이렇게 하면, $N_B$를 받는 A의 경우, $N_B$ history와 비교해서 fresh하면 B를 믿으면 된다. 대표적으로는 timestamp를 이용한다.

 

 

Kerberos

MIT에서 개발한 Network authentication protocol이다.

• Needham-Schroeder protocol 기반이다.
• Authentication과 Secure communication을 제공해준다.
• Symmetic cryptography이다.

 

Needham-Schroeder에서의 문제점은 새로운 서비를 이용할 때마다 $k_{A,T}$를 사용하는 것이다. Kerberos는 TTP를 AS, TGS로 분리함으로써 이를 해결한다.

 

그 전에 간단하게 용어를 살피고 간다.

• AS : authentication server
• SS : service server
• TGS : ticket granting server
• TGT : ticket granting ticket

 

Kerberos의 통신 성립 과정은 다음과 같다.

Kerberos의 클라이언트가 서비스를 이용하기 위한 통신 과정이다.

클라이언트는 long-term shared secret key를 이용해서 AS에 인증하고 TGT를 받는다. 클라이언트는 TGT로 TGS에 인증하여 SS 접근에 필요한 ticket을 받는다.

 

 

Kerberos protocol

구체적으로는 다음과 같다.

 

*로그인하는 경우

클라이언트는 AS로부터 TGT를 받는다.

 

*서비스를 사용할 때마다 한번씩

클라이언트는 TGS로부터 SS ticket을 받는다.

 

*서비스 session마다 한번식

세션마다 서비스와 클라이언트는 인증을 해야한다. 클라이언트는 SS ticket으로 서비스를 사용할 수 있다.

 

 

Kerberos drawback

• TGS에 대한 의존도가 높다.
  = Single point of failure
• Tight clock synchronization에 의존한다.
• 주로 Organazation 내부에서 유용하다.

 

+$\alpha$ : Kerberos v4의 경우 DES 하나만 사용하고 IP 주소만 사용하는 등의 단점이 있었지만, v5로 넘어오면서 해결되었다.

 

 

Public key and Trust

Public key, $P_A$가 A의 public key임을 아는 것은 다른 문제가 된다. 일반적으로 public key를 뿌리는 방법은 2가지가 있다.

• Public announcement : 그냥 전부 다 주기
• Public available directory : 공유 공간에 두기

 

2가지 방법 모두 forgery(위조)에 취약하다.

 

 

Public key certificates

Contents는 trusted public key나 Certificate Authority, CA에 의해서 디지털 서명된다. 그럴 경우 신뢰할 수 있다고 본다.

 

예를 들어서, A→B (encrypted message)인 상황이라면, A는 B의 public key에 대한 certificate를 받아서 확인하고 전송할 수 있다.

Public key certification

 

 

X.509 certificates

인증서의 형식을 정의하는 X.500의 인증 프레임워크가 X.509이다.

• Public Key Infrastructure, PKI 프레임워크
• Public Key와 ID 정보가 인증서에 포함된다.
• 인증서는 CA에 의해서 발행된다.
• 주로 SSL, IPSec, SET에 쓰인다.

 

Public Key Infrastructure

인증서는 CA의 서명이 있어야 신뢰가능하다. 그런데 CA가 모든 인증서를 관리하는 것은 현실적으로 불가능하다. 따라서 계층구조적 관리가 들어간다.

 

계층 구조의 CA

User1과 User4가 서로 인증하려고 하면,

• User1 : root CA 가지고 있음
  User4 → User1 : CA<<CA3>>, CA3<<User4 public key>>
  (CA에서 발행한 CA3 인증서는 CA<<CA3>>라고 표현한다.)
• User1 : 가지고 있는 CA로 CA<<CA3>> 인증서 검증
              CA<<CA3>>에서 CA3 추출
              추출한 CA3로 CA3<<User4>> 인증서 검증
              CA3<<User4 ID>>에서 User4의 public key 추출

 

How to obtain a certificate

2가지 방법이 있다.

• Self-signed certificate
  (unlikely to be accepted by others)
• CA vendors에게 인증서 받기
  과정은 다음과 같다.
  • Generate private key
  • Generate Certificate Signing Request, CSR
  • Send CSR to CA
  • CA sends signed certificate to requestor

 

 

Authenticated Diffie-Hellman

DH도 인증서와 함께 사용할 수 있다.

 

 

Transport Layer Security, TLS

Secure Socket Layer, SSL이라는 이름이었던 Web security를 위한 protocol이다. 데이터 전송 시에 평문이 아니라 암호문을 전송한다. 개인정보 보호에 따라서 SSL은 필수로 사용된다.

 

SSL은 크게 Session과 Connection으로 나뉜다.

• Session : 두 서버의 관계
• Connection : 연결 방법

 

보안 세션은 Handshake protocol에 의해 생성된다.

• Public key cryptography를 이용해 shared secret key를 생성한다.
• 서버에서 클라이언트 인증을 위해 signed certification을 사용한다.

Record Layer도 존재한다.

• 데이터는 negotiated key, encryption function에 의해 전송된다.

Handshake 과정이다.

 

 

Usage of SSL/TLS

TLS는 Application layer와 Transport layer 사이에 위치한다. HTTP, SMTP 등을 보호한다.

사용 예시는 다음과 같다.

• Public key와 인증서를 이용해 서버를 인증할 수 있다.
• Client와 Server는 cipher suite를 협상해서 결정한다.
  • Key exchange algorithm ; RSA, Diffie-Hellman, ...
  • Encryption algorithm ; RC4, DES, AES, ...
  • MAC algorithm ; HMAC-MD5, HMC-SHA1, ...

 

 

Real world problem

• Heartbeated SW bug in OpenSSL
• SSL 인증서 validation 오류
• Non-random private key in RSA, n=pq
  (종종 같은 prime으로 생성됨)
• Pre-computation으로 TLS에서 Diffie-Hellman을 break할 수 있다.

 

 

Viewing HTTPS web sites

Indicator를 통해서 TLS가 동작하고 있는 것을 확인할 수 있다. Phishing attack 등을 방지할 수 있다.

 

하지만 여전히 security 문제는 존재한다.

• 일반 사람들은 잘 모름
• 일반 사람들은 잘 확인 안함
• 브라우저가 취약한 경우, 이상한 indicator로 바뀜
• 저장된 인증서의 권한 정보가 변하는 경우