반응형
PGP (Pretty Good Privacy)
PGP는 인터넷 전자우편을 암호화하고 복호화하는데 사용된다. Phil Zimmermann이라는 사람이 개발을 했는데 개발 후에 이 사람이 수출을 시도하려다 미국에 저지 당하게 된다. 하지만 결국 빼냈고 나중에 와서는 공개로 바뀌었다. 지금 보면 이것은 굉장히 멋진 아이디어라고 생각한다. 그 당시 이것이 왜 국가기밀이었는지 실감이 날 정도이다. 이런 천재적 발상을 한 개발자가 존경스럽다.
왼쪽은 Alice 오른쪽은 Bob이란 친구다. Alice는 Bob에게 기밀성을 유지하는 이메일을 보내고 싶어한다.
Alice의 입장
- 먼저 Alice는 Ks라는 대칭키를 제작한다. (이것을 Bob과 안전하게 나눠갖는 것이 목적)
- 보내려는 메세지 m 을 Alice가 제작한 대칭키 Ks로 암호화 한다.
- 그 대칭키 Ks를 Bob의 공개키 Kb 로 암호화 한다. (포인트!!) -> 이 말은 Bob만이 자신의 비밀키로 저것을 열 수가 있음.
- 이 둘을 Bob에게 보낸다.
Bob의 입장
- Bob은 자신의 비밀키로 Ks를 획득한다.
- 그리고 Ks로 잠긴 메세지박스를 Ks로 열어 m을 획득한다.
사용자 인증authentication과 기밀성confidentiality 둘 다 보장하는 시나리오 (무결성까지!)
- Alice는 메세지를 Hash하여 mac을 획득한다. H(*) 단계
- 그것을 자신의 private key(비밀 키)로 잠근다. (전자서명의 단계)
- 그리고 메세지와 잠근 mac을 (서명한) Alice가 생성한 대칭키 Ks로 잠가서 Bob에게 보낸다.
- 대칭키 Ks도 Bob의 public key(공개키)로 잠가서 보낸다.
- 그 2개의 소포를 받은 Bob은 먼저 자신의 private key(비밀 키) 로 앨리스가 생성한 Ks를 획득한다.
- 그리고 획득 한 Ks로 나머지를 열어서 어떤 메세지와 누군가(Alice)가 서명한 Mac을 발견한다. (그 메세지는 아직 누가 보냈는지 모름)
- Alice의 public key로 열었더니 Mac이 나왔다! (Alice가 보낸 것을 확신 ! 인증단계)
- 그리고 메세지를 해시해서 Mac과 일치하는지 확인한다.
Kerberos (커버로스)
서버가 여러대로 늘어나게 되는 상황에서 각 서버에서 user들의 관리는 점점 어려워진다. 즉 각 서버별로 접근 가능한 client들을 관리하기가 힘들어 지는 것이다. 중간에 AS(인증서버)와 TGS(티켓서버)를 두어 관리를 시킨다.
1. User는 인증 서버(AS)에게 TGS(티켓 서버)와 이야기 하고 싶다고 메세지를 보낸다. 즉 (User ID, TGS이름) 이 두개를 K(user-as)로 암호화 하여 보낸다.
2. TGS는 이것을 열어보고 User가 TGS와 통신하고 싶다는 것을 안다. 그러면 AS는 User 와 TGS가 통신할 세션키 K(user-tgs) 를 생성하고 K(user-tgs)와 UserID를 K(as-tgs)로 암호화하여 보낸다.
이렇게 되는데 K(as-tgs) 는 AS서버와 TGS서버 둘 만이 아 는 키이다. 이것으로 암호화한 저 두 개의 데이터를 묶어서 TICKET (티켓)이라고 한다. 이것을 받은 유저는 열어 봤을 때 저 세션 키만 알 수 있고 티켓은 열 방도가 없다.
3. 유저는 자신의 UserID를 받은 세션키 K(user-tgs)로 암호화를 하고 받은 티켓을 TGS에 보낸다.
4. TGS는 이것을 열어보고 유저를 확인 한뒤 아까 위에서봤던 (user와 as간의 통신) 과 같은 방법으로 user와 Server를 통신하게 한다.
Kerberos의 단점
- Single Point of Failure : 커버로스 서버가 다운되면 새로 들어오는 유저가 서버에 접속할 수가 없게 된다.
- AS, TGS, SERVER들 간에 서로 비밀키를 알고 있어야 해서 동기화 문제가 존재한다.
- 티켓이 유저(client)에 존재하므로 탈취가능성이 있다.
반응형
'프로그래밍 > 컴퓨터보안' 카테고리의 다른 글
[컴퓨터보안] 해시 (Hash Function) 함수 보안 (0) | 2018.12.08 |
---|---|
[컴퓨터보안] El Gamal (엘가말) 과 Diffie - Hellman (디피헬만) 프로토콜 (0) | 2018.12.08 |