Security Protocols

특정 상호작용을 보장하기 위해 준수해야할 규칙 → Secure Mechanism

• Human protocols - 사람 상호작용 규칙
  Networking protocols - 네트워크 소통 시스템(HTTP, FTP)
• Security protocols - Security application에서의 소통 규칙 (TLS -SSL, Kerberos)

---

Protocol의 결함은 미묘 → Right protocol 얻기 쉽지 않다.

• 전통적인 security protocol도 결함이 있다. (WEP - WiFi 보안 알고리즘, GSM - 이동 통신 보안 표준, IPSec 초반)
• 구현 에러도 발생할 수 있다.

< Ideal Security Protocol >

• Must satisfy security requirements → precise해야됨.
• Efficient - 적은 연산량, bandwith 사용량, delay
  (Asymmetric Public-key는 느리다.)
• Robust - 환경이 변하더라도 작동, 공격자에 저항
• 사용하고 구현하기 쉽다. / Flexibility

< 기본 Authentication 방식 >

“Replay” 공격에 취약하다.

→ Authentication over Internet(원격 인증)이 challenging!

(메시지 관찰, 메시지 replay-재현, 삽입 등 active 공격)

Challenge-response

목적 : “Replay”를 방지 → “Freshness” 보장

• Challenge: B → A임을 authenticate하고 싶다.
• A만 올바른 response를 제공할 수 있다. → B가 verify 가능

Nonce

Replay 방지, Freshness 보장

Nonce = (Number used ONCE)

Nonce는 사전 공유되어야한다.

 

→ Nonce로 무엇을 사용(challenge)? A가 Nonce로 뭘할까?(compute)? 어떻게 B가 verify?

   (전제) : Protocol 자체만 공격하고, 암호화 알고리즘은 안전하다.

• Challenge : Nonce
• Response : Hash값
• 문제점: Bob은 verify하기 위해 A의 password를 무조건 알아야 한다. (암호화 필요)

 

• Generic Challenge-Response

=> Hashing + Encryption

---

PKES(Passive Keyless Entry Systems)

• Keyless entry 허용: 차에 가까이가면 Nonce값을 보냄 → 수신자의 $ID$와 $E_k(ID, N)$ 전송
• (공격) : Signal을 증폭하거나 중계
• (방어) : UWB 기반의 새로운 radio protocol - (keyfob - 자동차)간의 정확한 거리 측정

Two-factor Authentication

System → User → Password Generators (+ PIN으로 시스템 log-on)

MIG-in-the-Middle Attack

NAMIBIA(적국) 입장에서 MIG가 자국 비행기인줄 안다. → Security Protocol 위조

• 처음에 NAMIBIA → MIG에 Nonce값을 보낸다.
• MIG가 자국 ANGOLA에 Nonce값 보내고, 이것을 받아 SAAF에 전달한 후 ${N}_k$를 받아서 MIG에 전달하면, 이를 NAMIBIA에 보낸다.
• 원래 MIG는 ${N}_k$를 알 수 없다.

Authentication with Symmetric key

A와 B가 symmetric key를 공유한다. → 서로만 알고 있고,

공개

(replay 방지 & verify 가능)

B는 A를 성공적으로 인증 BUT A는 B를 인증할 수 없다.

⇒ Mutual Authentication

---

Mutual Authentication

아무나 A가 될 수 있다! (공격자)

→ Secure One-way authentication protocol

1번

대신 Protocol을 2번 사용하자!

   B → A 인증 & A → B 인증

 

⇒ Mutual Authentication은 가능하지만, Reflection Attack으로 안전하지는 않다!

Reflection Attacks in Mutual Authentication

1명의 공격자가 서로 다른 A인 것처럼, Session을 2개 만들어 위조 가능

⇒ Key가 없으므로, 다른 Session으로 접속해 보낸다. ($R_B$ 받아 $E_k(R_B)$ 보냄.)

암호화 시 상대방에게 “자신”임을 알 수 있는 정보 같이 보냄.

→ 무조건 좋은 방법은 아니다…

 

---

< 그 외 Authentication Protocols >

항상 mutual authentication 필요? / Public-key Crypto는? / 환경의 변화는 Security failure의 흔한 경우 - ATM machine은 (magnetic-strip+PIN)과 (chip+PIN) 혼용

 

Authentication process에서 원하는 properties

• Session Key establishment
• Perfect Forward Secrecy (PFS)
• Message 교환 횟수 최소화

Public Key based Authentication

Asymmetric key를 악용할 수 있다.

상대가 Public key로 Nonce값 암호화 → Private key로 Nonce 복호화

 

안전하지 않다!

⇒ B가 공격자여서 악성 message 보낼 수도 있다.

아무 message나 보내도 A가 복호화

⇒ 2개의 key pair 필요

 

안전하지 않다!

⇒ B가 공격자여서 악성 message를 보내고 서명값을 얻을 수 있다.

⇒ 2개의 key pair 필요

 

Encryption & Signing에 같은 Key pair를 사용하는 것은 좋지 않다!

▶ (Encrypt&Decrypt) 위한 Key pair 1쌍
▶ (서명을 Sign&Verify) 위한 Key pair 1쌍

⇒ 2개의 Key pair 쓰자!

Session Key

특정 Session을 위해 공유한 Symmetric Key → A와 B끼리만 공유한다. → Confidentiality&Integrity

⇒ Authentication 완료 후 Session Key 공유

Authentication & Session Key

 

(문제점) Mutual Authentication이 없어  A 입장에서 B인지 인증할 수 없다.
   (K를 보내왔다는 것은 A만이 private key로 B가 보낸 것 복호화했다는 것 - B는 A 인증 가능)

   A의 Nonce값은 무의미

Public key based Authentication & Session Key

- (서명-> 암호화) with nonce
• Secure
- (암호화 -> 서명) with nonce
• Secure
- (서명-> 암호화) with timestamp
• Secure
- (암호화 -> 서명) with timestamp
• Insecure

• B가 서명해서 보냈으므로 Mutual Authentication!
• Session key가 안전하지 않다.
  → 누구나 Public key로 복호화가 가능하여 사실상 Session key 노출

서명 → 암호화 (Good)

• Mutual Authentication & Session Key

암호화 → 서명 (Good…)

누구나 public key로 {R,K}를 볼 수 있긴 하다.

---

PFS (Perfect Forward Secrecy)

공유 Key로 암호화 → 공격자가 암호문 record해놓았다가 나중에 Key 알게 됐을 떄 그동안의 recorded messages 복호화

완전 순방향 기밀성 보장 ⇒ 나중에도 recorded 암호문 Decrypt 불가능!

⇒ 매번 Session Key를 Update하자! (Diffie-Hellman)

 

Ephemeral Diffie-Hellman (일회성)

Meet-in-the-Middle 공격에 약하다 ⇒ 오른쪽

$g^{ab}$ 만든 후 각자 $a,b$ 잊어버린다.

→ A, B를 포함하여 아무도 공유 Key $K_S$ 복구 불가능

---

Mutual Authentication & Session Key & PFS

암호화 → 서명

Timestamps

Nonce 대신 “Time” 활용 → Kerberos와 같은 Security protocol에서 사용된다.

• Freshness & 사전에 공유하여 Mutual Authentication
• Clock skew 허용 → replay 위험 생길 수도 있다. (공격자 악용)

Public Key based Authentication & Timestamp

 

(서명 → 암호화)는 Good ↔ (암호화 → 서명)은 Bad

서명 후 암호화

서로 Session Key를 받게 되는데, 공격자가 ${T,K}_B$ 가로챌 수 있다.

---

만약 Key를 제거한다면, (암호화→서명)은 Good

A는 굳이 B에게 Key 보낼 필요 없다!

< Message manipulation & Protocol Attacks >

• Householder - Encrypted tokens (maginc #, types)
• Multi-function Authentication : 서명 악용, 거래에 사용되는 장치
• Mafia-in-the-Middle

→ 같은 Token이나 Crypto Key를 다른 application에서도 재사용?

Remote Key Management

Key distribution protocols (ex. Kerberos)

  믿을 수 있는 제 3자의 존재($S$) 가정

실제로 사용되는 Needham-Schroeder Protocol

• Timestamp → Nonce
• 제 3자가 중개하고, $K_{AB}$ symmetric key 기반

Kerberos protocol

A distributed Access Control System (Windows, Linux 모두 LAN 인증)

3개의 서버 사용 ↔ Client와 개별적 작동 ⇒ 3개 서버 동기화(sync) 이슈

• AS (Authentication Server)
• TGS (Ticket Granting Server) → ticket : 사용자 ID, ip 주소, timestamp, session key 등
• RS(SS) (Resource/Service Server) : 궁극적으로 통신하기 위한 서버 - ID

인증 순서 : AS → TGS → RS(SS)

Timestamp + Lifetime