정보보안기사(필기) - 애플리케이션 보안(전자상거래 보안)

1. 전자화폐

디지털 서명이 있는 금액 가치 정보로, 전자기호 형태로 화폐적 가치를 저장하여 상품 등 구매에 사용할 수 있는 전자적 지급 수단이다.

 

Cf) 전자화폐 요구 조건

- 불추적성, 가치이전성(양도성), 분할성, 독립성(완전 정보화), 이중사용 방지, 익명성 취소

---

2. SET (Secure Electronic Transaction)

VISA와 MASTER CARD사에서 공동으로 개발된 프로토콜로, 전자 서명과 인증서를 통한 안전한 거래가 가능하다. (SSL에 비해 상대적으로 느리다.)

 

Cf) SET 이중서명(Dual Signature)

- 사용자는 판매자에게 지불 정보(계좌 정보)를 숨기고 싶음

- 사용자는 PG(Payment Gateway)에게 주문 정보를 숨기고 싶음

- PG는 판매자가 전송한 결제 요청이 실제 고객이 의뢰한 정보인지 확인하고 싶음

 

Cf) SET 장점과 단점

장점	단점
- 전자상거래의 사기 방지 - 기존의 신용카드 기반을 그대로 사용	- 암호 프로토콜이 너무 복잡함 - RSA 속도 저하, 카드 소지자에게 전자지갑 S/W 요구

---

3. SSL(Secures Socket Layer)

개인 정보를 전송하는 네트워크 구간은 Sniffer 등으로부터 보호하기위해 보안 서버를 사용해서 송/수신되는 데이터를 암호화하는 것이 안전하다.

암호문 전송을 위해 RSA 공개키 알고리즘을 사용하며, X.509 인증서 지원, 443 포트 사용, Transport ~ Application Layer에서 동작한다.

 

1) SSL 보안 서비스

보안 서비스	세부 내용
인증(Authentication)	- 거래하고자하는 사이트가 검증된 사이트인지 개인정보를 송신하기 전에 사이트를 인증
무결성(Integrity)	- 송신자에서 상대편까지 송신 중 공격자나 제 3자에 의해 데이터가 위/변조되는 것을 방지
기밀성(Confidentiality)	- 여러가지 암호화 방식을 사용하여 데이터의 송/수신 중 불법적인 접근을 통제 - 데이터가 공격에 의해 유출되더라도 쉽게 읽힐 수 없는 형태로 변환

 

2) SSL Handshaking

TCP 연결 후 웹 브라우저는 443 포트를 호출하여 3-way handshaking을 수행하며, 그 과정은 아래와 같다.

 

a. Client -> Server

- 'Client Hello' 메시지를 전송하는데, 웹 브라우저에서 지원하는 SSL 버전, 암호화 알고리즘 등의 정보가 포함됨

- 'Random'을 전송하는데, 이는 Replay Attack을 방지하기 위한 임의적인 숫자임

 

b. Server -> Client

- 서버가 지원할 수 있는 알고리즘과 함께 'Server Hello' 메시지를 전송

- 웹 서버도 'Random'을 전송

 

c. Client -> 공인 또는 사설 CA

- 전달받은 서버 인증서를 CA를 통해 신뢰할 수 있는 서버인지 확인

* 공인 CA 인증서: 인증서의 공개키로 복호화

* 사설 CA 인증서: 브라우저에 저장된 CA 리스트에 없기 때문에 https 경고 표시

 

d. Client -> Server

- 암호 통신에 사용할 Session Key 생성 후 서버의 공개키로 암호화해 Pre-master Key를 만들어 서버에 전송 (Change Cipher Spec)

- 서버에게 협의 종료를 전달 (Finished)

 

e. Server -> Client

- Client의 응답에 동의하고 협의된 알고리즘의 적용을 알림 (Change Cipher Spec)

- 클라이언트에게 협의 종료를 전달 (Finished)

SSL Handshaking 과정 (https://teacheryoon.tistory.com/5)

 

3) OpenSSL 사용

SSL을 사용하여 보안 서버를 구축하기 위해서는 웹 서버에 OpenSSL 패키지를 설치하고 개인키와 인증서 등을 생성해야 한다.

 

Cf) OpenSSL 보안 취약점 (HeartBleed 취약점)

- OpenSSL 암호화 라이브러리의 Heartbeat라는 확장 모듈에서 발생

- 웹 브라우저가 Request 했을 때, 데이터 길이를 검증하지 않아 메모리에 저장되어 있는 평문의 64KByte가 노툴되는 현상

---

4. IPSEC (IP Security)

인터넷 상에서 전용 회선처럼 이용 가능한 가상의 전용 회선을 구축하여 데이터를 도청당하는 등의 행위를 방지하기 위한 통신 규약으로, 전송 방법으로는 터널 모드와 전송 모드가 있다.

종류	설명
전송 모드	- 출발지에서 암호화를 하고 목적지에서 복호화가 이루어지므로 End-to-End 보안을 제공
터널 모드	- VPN과 같은 구성으로, 일반 패킷이 보내지면 중간에서 IPSec을 탑재한 중계 장비가 패킷 전체를 암호화하고 중계 장비의 IP 주소를 붙여 전송

https://teacheryoon.tistory.com/5

Cf) IPSEC Header 구조

종류	설명
AH	- 데이터 무결성과 IP 패킷의 인증을 제공 (MAC 기반) - Replay Attack으로부터 보호 - 인증 시 MD5, SHA-1 인증 알고리즘 사용 - 수신자는 같은 키를 이용하여 인증 값 검증
ESP	- 전송 자료를 암호화하여 전송하고, 수신자가 받은 자료를 복호화하여 수신 - AH와 달리 암호화를 제공(대칭키, DES, 3DES 알고리즘) - TCP/UDP 등의 Transport Layer까지 암호화할 경우, Transport Mode - 전체 IP 패킷에 대해 암호화할 경우, Tunnel Mode

---

5. OTP (One Time Password)

매번 다른 난수를 생성하여 인증 시 패스워드를 대신하는 방법으로, 높은 보안수준을 가진 사용자 동적 비밀번호이며 사용된 비밀번호는 일회용으로서 다시 생성되지 않는다.

 

1) 동기화 방식

OTP 생성기와 은행의 OTP 인증서버 사이에 동기화된 기준값에 따라 OTP가 생성되는 방식으로, 동기화된 기준값에 따라 시간 동기화 방식과 이벤트 동기화 방식으로 분류된다.

 

[시간 동기화 방식]

- OTP 생성 매체가 매시간 비밀번호를 자동으로 생성

- 시간을 기준값으로 하여 OTP 생성 매체와 OTP 인증서버가 동기화

- 간편한 장점이 있지만 일정 시간 은행에 OTP를 전송하지 못하면 다시 새로운 OTP가 생성될때까지 기다려야 함

[이벤트 동기화 방식]

- OTP 생성 매체와 인증서버의 동기화된 인증 횟수를 기준값으로 생성

- OTP 생성 매체에서 생성된 비밀번호 횟수와 인증서버가 생성한 횟수가 자동으로 동기화되기 때문에 시간 동기화의 불편성을 완화

 

2) 비동기 방식 : 질의응답(Challenge-Response)

- 사용자의 OTP 생성 매체와 은행의 OTP 인증서버 사이에 동기화되는 기준값이 없음

- 사용자가 직접 임의의 난수를 OTP 생성 매체에 입력하여 OTP를 생성하는 방식

- 사용자가 인증서버로부터 받은 질의 값을 OTP 생성 매체에 직접 입력하면 응답값이 생성된다.

 

 

---

# 참고

해당 글은 '이기적 정보보안기사 필기 1권 이론서'을 읽으며 필요한 부분만 정리한 내용입니다.