OSI 프로토콜에서의 암호화

1. SSH(Secure Shell)

- 원격 시스템에서 안전하게 통신하기 위해 암호화된 세션으로 연결

- FTP, Telnet, rlogin과 같은 프로그램보다 확장된 보안 제공

- 암호기법 : 공개키(IDEA, DES, 3DES, RC4, Blowfish)

- 키 교환 : RSA

- 전송계층에서 작동

2. SSL (Secure Socket Layer)/TLS(Transport Layer Security)

- 인터넷을 통한 개인 메시지의 전송을 위해 Netscape에서 개발한 프로토콜

- 브라우저와 웹 서버 사이의 통신 위한 세션 기반 프토토콜

- OSI 7 Layer 중 응용계층과 전송계층 사이에 위치

- 암호기법 : RSA 공개키/개인키 암호화 방식 사용(IDEA, DES, RC2, RC4)

- 키 교환 : RSA

- 서명 : RSA

- 해쉬함수 : MD2/4, SHA

- 대칭키, 비대칭키, 디지털 서명을 함께 사용 

- 제공하는 보안서비스 : 기밀성, 무결성(MAC제공), 인증(서버인증), 압축

> 작동 매커니즘

클라이언트와 서버 사이에 HTTP가 연결되어 있는 상황이라고 가정한다.

1. 클라이언트가 서버에 Secure file을 request.

2. 서버에서는 서버정보와 서버의 공개키를 클라이언트에 전송함으로써 검증한다.

3-1. 클라이언트에서는 세션키를 생성하고, 인증서를 검증한다.

3-2.  서버로 부터 전송받은 공개키로 세션키를 암호화한다.

4. 클라이언트에서 서버로 암호화한 세션키를 전송한다.

5. 서버에서는 암호화 된 세션키를 복호화 한다.

(이 때, 개인키로 복호화하여 세션키를 얻고, 세션키로 secure file을 암호화한다.)

6. 서버에서는 secure file을 암호화 하여 클라이언트에 전송한다.

7. 클라이언트에서는 secure file을 세션키로 복호화한다.

3. S-HTTP (Secure-HTTP)

 

- 각각의 메시지를 안전하게 전송하기 위한 프로토콜 방식. HTTP의 확장판

-> 응용레벨에서의 메시지 암호화로 안전한 통신을 보장함.

- SSL에비해 더 많은 보안 매커니즘 구현

- HTTP만 지원한다는 한계점과 웹서버개발의 한계로 보편화 되지 못함.

- 암호기법 : IDEA, DES, 3DES, RC4

- 키 교환 : RSA/ DH

- 서명 : RSA

- 해시함수 : MD5, SHA-1

- 제공하는 보안 서비스 : 기밀성, 인증, 무결성

> SSL과 SHTTP 비교

	SSL(Secure Socket Layer)	S-HTTP (Secure HTTP)
범위	telnet, ftp, 프로토콜 단위	웹
인증 방식	클라이언트의 인증이 선택적	각각 인증서 필요
인증서	서버에서 인증 가능	클라이언트에 인증서 보냄
인증 단위	서비스 단위	메시지 단위

4. SET(Secure Electronic Transaction)

- VISA와 MASTER Card사에 의해 공동으로 개발

- 상거래 인증의 상호작용 보장

- 온라인에서의 안전한 신용카드사용을 위한 결제 프로토콜

- 전자서명과 인증서를 통한 안전한 거래(PKI:Public Key Infrastructure이용)

- 응용계층에서 작동

- 암호기법 : DES

- 키 교환 : RSA

- 서명 : RSA

- 해쉬함수 : MD2/4/5, SHA-1

- 제공하는 보안서비스 : 기밀성, 무결성, 인증, 부인봉쇄

- 장점 : 기존의 신용카드 기반을 그대로 활용 가능

- 단점 : 복잡한 암호 프로토콜, RSA에서의 프로토콜 속도 비효율성, 별도의 s/w 필요

>SET의 구성

- 사용자(카드소지자)

- 판매자

- PG(Payment Gateway) : ex)이니시스...

- 발급은행 : CA를 운영하여 사용자에게 인증서 발행

- 지불처리은행 : CA를 운영하여 판매자에게 인증서 발행

- 인증기관 : 사용자, 판매자, PG의 정당성 보증

>SET을 이용한 신용카드 거래 과정

1. 사용자의 구매정보와 결제정보가 담긴 정보에 각각 서명을 생성한다.(이중서명)

2. 사용자의 구매정보는 판매자의 공개키로 암호화하고

사용자의 결제정보는 PG의 공개키로 암호화한다. 

이 때 암호화 된 두 정보를 전자봉투의 형식으로 판매자에게 전송한다.

3. 구매정보와 이중서명 확인 후 결제정보를 PG에 전송한다.