Security

9.1 Introduction to Security Security policy Security mechanism

9.1.1 Security Threats, Policies, and Mechanisms(1) Dependability Component는 client에게 서비스를 제공 Component는 다른 component로부터 서비스를 요구할 수도 있음 Component는 다른 component에 의존할 수 있음 Availability 인가/허가(authorize) 받은 entity에 대해서 접근을 요구할 수 있음 Reliability (신뢰성) 서비스가 계속되어야 함 Safety 사고의 확률이 매우 낮아야 함 Confidentiality 인가 받지 않은 정보의 유출이 없어야 함 Integrity (무결성, 완전성) 인가 받은 정보에 대한 사고나 악의적인 변경이 없어야 함

9.1.1 Security Threats, Policies, and Mechanisms(2) The Players Subject Entity capable of issuing a request for a service as provided by objects Channel The carrier of requests and replies for services offered to subjects Object Entity providing services to subjects 보안 위협 (security threat)의 유형 가로채기 (Interception) 끼어들기 (Interruption) 변경 (Modification) 위조 (Fabrication)

9.1.1 Security Threats, Policies, and Mechanisms(3) The threats Threat Channel Object Interruption Preventing message transfer Denial of Service Inspection Reading the content of transferred message Reading the data contained in an object Modification Changing message content Changing an object’s encapsulated data Fabrication Inserting message Spoofing an object Spoof:도용

9.1.1 Security Threats, Policies, and Mechanisms(4) Security Policy System내에서 entity에 사용되거나 금지되는 행위에 대한 정확한 기술 정책에 따라서 보안 방법 (security mechanism)을 적용

9.1.1 Security Threats, Policies, and Mechanisms(5) Security Mechanism 보안 위협을 방지하기 위한 기법 암호화 (Encryption) 전송하는 데이터를 공격자(attacker, intruder)로 하여금 이해할 수 없도록 함 무엇인가 변경되었나를 확인할 수 있도록 하여 완전성(integrity)를 확인 할 수 있음 인증 (Authentication) 사용자나 다른 entity의 식별자를 검증 일반적으로 암호를 사용 인가/허가 (Authorization) 어떤 서비스에 대한 사용 권한이 있는가를 확인 감사 (Auditing) 적절한 방법으로 entity에 접근이 이루어졌나를 확인 공격에 대한 분석에 유용하게 사용될 수 있음

9.1.2 Design Issues (1) Focus of control Layering of security mechanisms Simplicity

9.1.2 Design Issues (2) Focus of Control Data is protected against wrong or invalid operations Data is protected against unauthorized invocations Data is protected by checking the role of invoker

9.1.2 Design Issues (3)

9.1.2 Design Issues (4)

9.1.2 Design Issues (5)

9.1.2 Design Issues (6) Layering of Security Mechanisms Trust and security Security Technical Trust Emotional

9.1.2 Design Issues (7) Security를 어떤 곳에 구현 할 것인가?

9.1.2 Design Issues (8) Layering of Security Mechanisms Alice가 site 사이의 통신에 사용하는 security를 신뢰하는가?

9.1.2 Design Issues (9) Layering of Security Mechanisms Alice가 신뢰하지 못한다면 스스로의 방법을 사용할 것임 SSL (Secure Socket Layer) Secured RPC SSL을 신뢰하지 못하여 Secured RPC를 선택 내부적으로 신뢰하지 못하는 SSL이 사용될 수 있음

9.1.2 Design Issues (10) Distribution of Security Mechanism

9.1.2 Design Issues Simplicity 어떤 layer에 적용하는 것이 단순한가? Link-level encryption 가로채기(interception)을 예방하기 위해서 사용할 수 있는 단순하고 이해하기 쉬운 방식 Alice는 Bob만이 메시지를 받는지 확신하기를 원한다면? User-level authentication 서비스를 필요로 할지도 모름

9.1.3 Cryptography 분산 시스템에서 보안의 기본으로 암호화 기법을 사용 Symmetric system Data Encryption Standard (DES) 암호/복호에 동일한 키를 사용 송/수신 측이 암호 키를 공유 Asymmetric system Public-Key Cryptosystems RSA (Rivest, Shamir, and Adleman) 암호/복호에 다른 키를 사용 Private/Public 키를 사용 Hashing system MD5 (Message Digest) 암호화 만을 하며 고정 길이 요약을 생성해 냄 복호화는 없으며 비교만이 가능함

Threat and Attack Threat Attack 잠재되어 있는 가능한 위험 시스템 보안에 대한 직접적인 도전 또는 공격 수동적인 공격 (Passive Attack) 능동적인 공격 (Active Attack)

Passive Attack Release of message contents

Passive Attack Traffic analysis

Passive Attack 공격을 발견하기 어려움 데이터에 어떤 변경도 이루어지지 않기 때문에 발견보다 예방이 중요함

Active Attack 비합법적 메시지 생성 합법적 메시지를 거부 시스템 자원을 이용하지 못하도록 함 Creating illegitimate message 가장 - Masquerade (who) 재현 - Replay (when) 변경 - Modification of message (what) 합법적 메시지를 거부 Denying legitimate message 거절 - Repudiation 시스템 자원을 이용하지 못하도록 함 Making system facilities unavailable

Active Attack Masquerade One entity pretends to be a different entity.

Active Attack Replay A message is captured and retransmitted later

Active Attack A message is captured, and transmitted

Active Attack Repudiation Denial of sending or receiving legitimate message

Active Attack Denial of service Making system facilities unavailable

Active Attack 예방하기 어려움 Because of new vulnerabilities So, the goal is to detect active attacks and to recover as soon as possible. Vulnerability: 취약성

DES RSA MD5

9.2 Security Channel (1) Client와 Server 사이에 보완 통신을 어떻게 연결할 것인가? 인증, 무결성, 기밀성을 요구 자원의 접근을 허가 (Authorization) 할 것인가?

9.2 Security Channel (2) Both parties know who is on the other side (authenticated) Both parties know that messages cannot be tampered with (integrity) Both parties know messages cannot leak away (confidentiality)

9.2.1 Authentication (1) 인증과 무결성 인증과 무결성은 서로 의존 관계에 놓임 Trudy에 의해서 Alice와 Bob 사이의 통신이 공격 받는다면? 무결성 없는 인증 Alice의 메시지는 인증됨 Trudy가 가로채 메시지를 수정 인증이 의미가 없음 인증없는 무결성 Trudy가 Alice의 메시지를 가로챔 Bob에게 Alice의 메시지라 속이고 데이터를 보냄 무결성은 의미가 없음

9.2.1 Authentication (2) Authentication Based on a Shared Secret Key Challenge-response protocol 1: Alice send ID to Bob 2: Bob send challenge RB to Alice 3: Alice enc RB with shared key KA,B Bob now knows he is talking to Alice 4: Alice send challenge RA to Bob 5: Bob enc RA with KA,B. Alice now knows that she is talking to Bob

9.2.1 Authentication (3) 3단계로 줄임

9.2.1 Authentication (4) 반사 공격 (Reflection attack) (1) 송신자가 생성한 메시지를 가로챈 공격자가 그 메시지를 다시 송신자에게 재전송하여 접근 권한을 얻는 형태의 공격 방법 사전에 암호 키를 공유한 송신자와 수신자는 상대방 식별을 위하여 각각 난수값을 생성하여 전송하고 이에 대한 암호값을 요청한 후 수신된 암호값을 복호화하여 그 결과 값이 자신이 송신하였던 난수값과 일치하는지 여부를 확인하여 상대방을 인증한다 이때 공격자는 송신자가 보낸 난수값에 대한 암호값을 알기 위해 송신자가 보낸 난수값을 송신자에게 재전송하고, 이를 수신자의 난수값으로 인식한 송신자는 이에 대한 암호값을 공격자에게 전송하게 된다 공격자는 이 암호값을 다시 송신자에게 전송함으로써 자신을 인증시키고, 그 결과 접근 권한을 획득하게 된다.

9.2.1 Authentication (5) 반사 공격 (Reflection attack) (2)

9.2.1 Authentication (6) 중간자 공격 (man-in-the-middle-attack) Alice는 키로 항상 홀수를 Bob은 항상 짝수를 사용한다면 Bob은 reflection attack을 감지할 수 있음 Bob Mallory(MITM) Hi Bob, It’s Alice. Give me your key Alice [Bob’s Key] [Mallory’s Key] “Meet me at the bus stop!” [Encrypted with Mallory’s key] “Meet me in the windowless van at 22nd Ave!” [Encrypted with Bob’s key] http://en.wikipedia.org/wiki/Man-in-the-middle_attack

9.2.1 Authentication (7) Authentication Using a Key Distributor Center (KDC) One of problem with using Shared secret key for authentication is scalability N host N-1 host와 키를 공유 각 host는 N-1개의 key를 관리 전체 시스템은 N(N-1)/2의 key를 관리 N이 매우 크다면? KDC Host의 키를 관리

9.2.1 Authentication (8) The principle of using KDC

9.2.1 Authentication (9) KDC를 이용할 때 Bob이 secure channel에 대한 준비가 되기 전에 Alice가 메시지를 보낼 수 있음 ticket Using a ticket and letting Alice set up a connection to Bob

9.2.1 Authentication (10) Needham-schroeder authentication protocol 1978년 대칭키와 trent 개념을 사용하여 제안 Define Trent (KDC), Cathy : 인증서버 Alice (A), Bob (B) KA: Alice의 비밀 키 KB: Bot의 비밀 키 KS: 세션 키 RARB: 무작위수(nonce)

9.2.1 Authentication (11) Protocol A  KDC A  KDC EB(K,A) EK(RB) ID(A), ID(B), RA(Challenge) A  KDC 랜덤 세션키를 A와 B의 비밀키로 암호화 전송 EB(K,A) A는 메시지와 세션키 K를 구하고 KDC에 보내 RA를 검증 KDC가 B의 비밀키로 암호화한 메시지 전송 EK(RB) B는 비밀키로 메시지와 세션키 K를 구하고 또다른 random RB를 생성하여 세션키로 암호화하여 A에 전달 EK(RB-1) A는 세션키 K로 메시지를 구하고, RB-1을 랜덤하게 생성하여 세션키로 암호화 후 B에 전송 RA,RB,RB-1 Reflection Attack을 방지

9.2.1 Authentication (12) The Needham-Schroeder authentication protocol

9.2.1 Authentication (13) Alice || Bob || r1 Alice Cathy { Alice || Bob || r1 || ks || { Alice || ks } kB } kA Alice Cathy { Alice || ks } kB Alice Bob { r2 } ks Alice Bob { r2 – 1 } ks Alice Bob

9.2.1 Authentication (14) 취약점 대응방법 Old 세션키 취약점이 있음 2단계에서 세션키를 가로채 B에게 보내게 디되면 A는 속게 됨 대응방법 TimeStamp

9.2.1 Authentication (15) Protection against malicious reuse of a previously generated session key in the Needham-Schroeder protocol

Mutual authentication in a public-key cryptosystem

9.2.2 Message Integrity and Confidentiality 무결성은 정보가 오직 허가된 사람들에게만 개방되고, 또 그들에 의해서만 수정될 수 있음을 보장 Confidentiality 메시지는 가로채어지지 않으며 감청/도청자에 읽을 수 없음을 보장 메시지를 보내기 전에 암호화 함으로써 기밀성을 보장할 수 있음

9.2.2 Message Integrity and Confidentiality (2) Digital Signature E-mail을 통한 거래에 서로 신뢰할 수 있는가? 서명을 통하여 메시지가 변조되지 않았음을 증명하도록 함 Digital Signing a message using public-key cryptography

9.2.2 Message Integrity and Confidentiality (3) Digital Signature Private Key Private Key 변경 전체 메시지를 Private Key로 암호화/복호화 하는 비용 Digital Signing a message using Message Digest

9.2.2 Message Integrity and Confidentiality (4) Digital Signature 전자서명은 문서나 메시지를 보낸 사람의 신원이 진짜임을 증명하기 위해 사용 전달된 메시지나 문서의 원래 내용이 변조되지 않았다는 것을 보증 부가적인 이득 쉽게 전송될 수 있고 쉽게 부인할 수 없으며 다른 사람이 흉내낼 수 없고 타임스탬프가 자동으로 유지됨

9.2.2 Message Integrity and Confidentiality (5) 예 유언장을 변호사에게 전송 유언장을 전자우편에 작성 해시된 유언장 메시지 작성 해시를 공개-개인키의 개인키로 암호화 암호화된 해시가 전자 서명이 됨 변호사 수신된 메시지의 해시 작성 해시된 메시지 해독을 위해 공개키 사용 해시가 맞다면 메시지는 유효함

9.2.2 Message Integrity and Confidentiality (6) Session Keys

9.2.2 Message Integrity and Confidentiality (4) Digital Signing a message using public-key cryptography

9.2.3 Secure Group Communication Confidential Group Communication Secrete Key Share Separate Share Key Public-key cryptosystem Secure Replicated Servers Byzantine Failure 모든 서버의 응답 확인 Replication Transparency 위배 Secrete Sharing 각각의 key를 공유하지만 전체가 key를 알지 못하도록 함 모두 참여할 때만 key를 드러내도록 함

9.2.4 Example: Kerberos (1) 개방된 컴퓨터 네트웍에서 서비스 요구를 인증하기 위한 안전한 방법 MIT의 Athena 프로젝트에서 개발 사용자가 인증 과정에서 암호화된 ticket을 요청 서버에 특정 서비스를 요구할 때 ticket을 사용 예 Telnet의 login을 요청할 때, 서버는 요청을 받아들기 전에 kerberos ticket을 요구 Ticket을 받기 위해서 인증 서버에 인증을 요청 인증 서버는 사용자의 패스워드에 기반한 session key와 서비스 요구를 나타내는 임의 값 생성 Session key를 Ticket Generation Server(TGS)에 전송 TGS는ticket을 발급 발급 일자와 시간을 포함 사용자는 ticket을 서버에 제출

9.2.4 Example: Kerberos (2) Kerberos의 장점 단점 서비스를 이용하기 위해서 네트워크에 사용자의 패스워드가 지나갈 필요가 없음 Spoofing 보안 침해에 대응할 수 있음 Spoofing 인터넷 주소를 속이거나 정당한 사용자로 가장 통신 프로토콜을 흉내 내어 서버에 접속 만료시간 내에 다시 ticket을 발급 받지 않고도 서비스를 이용 Timestamp를 이용하여 replay attack을 방지 익명의 인증이 가능 단점 신뢰할 수 있는 TGS가 요구 됨 모든 서버와 TGS 사이의 신뢰 관계가 요구됨

9.2.4 Example: Kerberos (3) User Ticket-Granting U Server Kerberos 사용자는 Kerberos Server 에서 인증 받음 인증 후, Ticket-Granting Server에 서버 접근 권한 요청 얻어낸 Service Ticket을 이용하여 해당 서버에 접근 User U Server Access Request Ticket-Granting Server Service Ticket Session key, Ticket Service Request authentication Unique Key Session Key Kerberos Server Other Server

9.2.4 Example: Kerberos (4) Kerberos session 초기화 User U Kerberos 사용자의 ID를 Kerberos Server에 전달 Kerberos Server는 Session Key(S)와 Ticket(TG)를 사용자에 전달하면서, Ticket Granting Server에 Session Key(S)를 등록 User U Kerberos Server Ticket-Granting 1. U’s Identity 2. Session Key (SG) 2. Session Key (SG), Ticket (TG) Encrypted Under Password Encrypted Under KKS,TGS

9.2.4 Example: Kerberos (5) Kerberos의 ticket 전달 User U Ticket-Granting 초기화 과정에서 얻어낸 Session Key(SG) 와 Ticket(TG) 를 이용하여 Ticket-Granting Server 에 ‘티켓’ 요청 Ticket-Granting Server가 ‘티켓’을 사용자에게 전달 ticket contains U’ id, A’s id, access rights, session key SA, expiration date User U Ticket-Granting Server 2. Ticket to A Server to Access Server A, SA (Encrypted Under KTGS,S), SA 1. Request to Access Server A Encrypted Under SG

9.2.4 Example: Kerberos (6) Authentication in Kerberos Secrete Key Session Key Secrete Key Ticket Authentication in Kerberos

9.2.4 Example: Kerberos (7) Setting up a secure channel in Kerberos

9.2.4 Example: Kerberos (8) KERBEROS Authentication Server (AS) Client User Logon Ticket Granting Ticket Authentication Server (AS) Client Ticket Granting Ticket Service Granting Ticket Service Granting Ticket Service for the Client Ticket Granting Server (TG) Application Server

9.2.4 Example: Kerberos (9) Authentication Server Client ID = ‘Alice’ Alice, Password Client Alice’s Password => K{Alice} Ticket-granting Ticket = EK1 ( ‘Alice’, K{Alice-TG} ) EK{Alice} ( K{Alice-TG}, Ticket-granting Ticket ) Service-granting Ticket EK{Alice-AS} ( Timestamp ) Ticket-granting Ticket EK {Alice-TG} ( Timestamp ) Ticket Granting Server (TG) Application Server (AS) Service-granting Ticket = EK2( ‘Alice’, K{Alice-AS}, ..) EK{Alice-TG} (K{Alice-AS}, Service-granting Ticket )

9.3 Access Control (1) RBAC (Role Based Access Control) Subject Role Object ACL (Access Control List) Ticket = Subject's role + Security 증표 LPP (Least Privilege Principle) Privilege per application session Authentication + Authorization User Side (인증서버) Login 인증 + Role 허가 + Security 증표 Server Security 증표 인증 + 액세스 허가

9.3 Access Control (2) Print file x Read file x Client (C) Printer Server (P) File Server (F) Download file x Privilege server CERTIFY? PAC SUBSET? Group 1 : SystemAdmin Group2 : Development group Owner : OWNER User : USER1 rw Group : Development group rwx Other : r

9.3.2 Firewalls (1) 침입차단시스템 인터넷 같은 외부 네트워크에 연결된 LAN과 같은 내부 네트워크를 외부의 불법적인 사용자의 침입으로부터 안전하게 보호하기 위한 정책 및 이를 지원하는 하드웨어 및 소프트웨어

9.3.2 Firewalls (2) 초크 점 응용 레벨의 네트워크 트래픽을 검사하여 거절하는 초크 점(choke point)으로서 동작 들어오고 나가는 패킷의 IP와 TCP 헤더를 검사하여 프로그램된 패킷 필터 규칙에 따라 패킷을 통과시키거나 거절 종류 패킷 필터링(packet filtering) 기법 응용 게이트웨이(application gateway) 방식

9.3.2 Firewalls (3) 패킷 필터링(packet filtering) 기법 TCP/IP 네트워크 구조에서 OSI 참조모델의 네트워크 계층과 전송 계층에 속하는 IP, TCP 혹은 UDP의 헤더에 포함된 내용을 분석하여 동작하는 방식 헤더에 포함된 송신/수신 IP 주소, 포트(port) 번호, 제어 필드 등의 내용을 분석하여 외부 네트워크에서 내부 네트워크로의 진입을 허용 또는 거절할지 결정하여 규칙(rule) 형태로 정의, 기술

9.3.2 Firewalls (4) 응용 게이트웨이(application gateway) 방식 TCP/IP의 Application layer에서 구동되는 응용 소프트웨어 이메일, Telnet, FTP, 웹 등과 같은 응용 서비스 수준에서 트래픽을 분석하여 외부 네트워크로부터 내부 네트워크로의 진입을 결정 응용 서비스 단계에서 액세스 제어를 제공할 수 있고, 응용 서비스의 사용에 대한 로그를 유지하여 감시, 추적 기능을 제공하며, 강력한 인증(strong authentication) 기법을 통해 적법한 사용자인지를 가려낼 수 있어 패킷 필터링 방식 보다 발전된 방식

9.3.3 Secure Mobile Code (대체-무선 랜 보안) (1)

9.3.3 Secure Mobile Code (대체-무선 랜 보안) (2) 무선 랜의 전송 거리 지향성 안테나 무지향성 안테나

9.3.3 Secure Mobile Code (대체-무선 랜 보안) (3) 무선 랜 프로토콜

9.3.3 Secure Mobile Code (대체-무선 랜 보안) (4) SSID (Service Set identifier) AP를 탐색하면 나타나는 AP 식별자 보안을 위해서 브로드캐스팅을 금지시킴 WEP (Wired Equivalent Privacy) 암호화하는 기본적인 방법, 접속할 때 키를 요구함 일반적으로 40bit의 키를 제공 (128bit까지 사용 가능) 키가 64bit 이하이면 스니핑을 통행 30만개 정도의 packet을 모으면 30분 이내에 복호화가 가능하다 함 암호화 키가 고정 됨 WPA (WiFi Protecte Access) 키 값이 쉽게 깨지는 WEP의 취약점을 보완하기 위해서 개발 데이터 암호화를 위해 TKIP(Temporal Key Integrity Protocol) 보안 표준을 사용 암호화 키를 특정 기간이나 일정 크기의 패킷 전송 후 자동으로 변경 시킴

9.3.3 Secure Mobile Code (대체-무선 랜 보안) (5) EAP (Extensible Authentication Protocol) 와 802.1X 무선 프로토콜 이외의 대체적인 인증 시스템 EAP 클라이언트와 RADIUS (Remote Authentication Dial-in User Service) 서버간의 통신을 가능하게 하는 프로토콜 802.1X 포트에 대한 접근을 통제하는 프로토콜 AP에 접속하려는 클라이언트가 네트워크에 로그인을 수행할 때까지 접근 권한을 얻지 못하게 함 클라이언트는 네트워크에 로그인하기 위해 ID와 패스워드를 입력 클라이언트와 RADIUS 서버는 상호 인증을 수행 RADIUS 서버와 클라이언트는 현재 접속한 세션에 대한 WEP키를 유도하며 ID와 패스워드와 같이 민감한 정보들은 모두 암호화 처리되는 방식을 통하여 스니핑과 다른 공격 등으로부터 보호됨.

9.3.3 Secure Mobile Code (대체-무선 랜 보안) (6) Challeng의 응답으로 ID/PW에 대한 Hash값을 구함

9.3.3 Secure Mobile Code (대체-무선 랜 보안) (7) Session key를 이용하여 Session Key 전달 Client 구별을 위한

9.3.4 Denial of Service (1) 일종의 훼방을 놓아 서비스를 하지 못하도록 하는 방법 Ping of death 패킷을 전송할 때 적당한 크기로 잘라서 전송하는 특성을 악용 네트워크 연결 상태 점검을 위한 ping 명령을 보낼 때 패킷을 최대(최대 65,500바이트) 한 크게 하여 공격 대상에게 전송 패킷은 네트워크게 수백 개의 패킷으로 잘게 쪼개져 보내지게 됨

9.3.4 Denial of Service (2)

9.3.4 Denial of Service (3) SYN Flooding (1) Flooding : 홍수, 범람 일반적으로 서비스를 제공하는 시스템에는 동시 사용자 수 대한 제한을 둠 존재하지 않는 클라이언트가 접속한 것처럼 속여 다른 사용자에게 서비스를 제공하지 못하도록 함

9.3.4 Denial of Service (4)

9.3.4 Denial of Service (5) SYN Flooding (2) 쓰리웨이 핸드셰이킹을 이용하는 TCP의 연결 과정의 문제점을 악용 서버는 클라이언트가 ACK 패킷을 보내올 때까지 SYN Received 상태로 기다리는 일정 시간 동안 가상의 클라이언트로 위조한 SYN 패킷을 수 없이 만들어서 서버에 보냄 서버의 가용 동시 접속자 수를 모두 SYN Received 상태로 만듦 해결 SYN Receive 대기 시간을 줄임

9.3.4 Denial of Service (6)

9.3.4 Denial of Service (7) Boink, Bank, TearDrop TCP는 다음의 방법으로 신뢰성 있는 데이터 전송을 보장하려 함 전송된 패킷의 순서를 확인 중간에 손실된 패킷이 있나 확인 손실된 패킷의 재 전송 요구 반복적인 재 요청과 수정을 공격 대상이 계속하게 함으로써 시스템의 자원을 고갈시킴 패킷의 시퀀스 넘버를 속임 해결 과부하가 걸리거나 계속 반복되는 패킷은 무시하고 버림

9.3.4 Denial of Service (8)

9.3.4 Denial of Service (9)

9.3.4 Denial of Service (10) Land Smurf (돈 세탁하는 사람) 패킷을 전송할 때 출발지와 목적지를 같은 IP로 만들어 공격 대상에게 보냄 Smurf (돈 세탁하는 사람) 공격자의 IP에 브로드케스트하도록 공격자 네트워크의 컴퓨터에 조작된 IP를 전송

9.3.4 Denial of Service (11) Mail Bomb 스팸으로 메일 저장 공간을 채워버림 DDoS (Distributed Denial of Service) 최종 공격 대상과 공격을 증폭시키는 중간자를 필요로 함

암호화 (1) Cryptography (암호학) CryptoSystem (Cipher)의 설계 비밀성 (secrecy) 진위성 (authenticity) 평문 (plaintext), 암호문 (ciphertext) 암호화 (encryption), 복호화 (decryption) 비밀 키 (secret key) Plaintext p Ciphertext c Encryption EK(p) = c Decryption DK(c) = m Secret Key K

암호화 (2)

암호화 (3) 치환 사용하는 키의 개수 암호화 방법 암호화 기법 일정한 규칙에 따라서 치환함으로써 암호화 송신자와 수신자가 같은 키를 사용 대칭키, 비밀키 암호화 비대칭키: 송신자와 수신자가 다른 키를 사요 비대칭키, 공개키 암호화 암호화 방법 스트림 암호화 연속적으로 글자를 입력해서 연속적으로 출력 블록 암호화 한 블록씩 동시에 암호화, 입력 블록에 대해여 출력 블록을 만듦 보통 64bit

암호화 (4) 비밀키 암호화 송수신자가 같은 키를 가지고 암호화 복호화를 수행함 단점 통신하는 두 당사자가 같은 키를 가짐 n명의 상대방이 있는 경우 비밀키가 n개가 됨 여러 상대방이 같은 키를 사용한다면 서로의 메시지를 읽을 수 있게 됨 부인 방지를 막을 수 없음 송신자와 수신자를 증명할 수 있는 인증을 할 수 없음 A와 B가 같은 키를 가질 때 두 사람이 메시지를 만들고 암호화한 다음, 서로 다른 사람이 보냈다고 주장할 수 있음

암호화 (5) DES (Data Encryption Standard) 루시퍼(Lucifer)로 알려진 IBM에서 개발된 것의 암호 알고리즈을 수정 1973년 미국국립표준국의 공모에서 1977년 표준으로 채택 56비트를 키를 사용하여 64비트 자료를 블록 암호화 함 입력으로 64비트 블록을 사용하고 64비트 블록을 출력함

암호화 (6) 공개키 암호화 (1) 1976년 Diffie와 Hellman에 의해 제안 키에 대한 정보를 공개함으로써 키 관리의 어렴움을 해결 공개키 : 암호화할 때 사용하는 키 비공개키 : 복호화 할 때 사용하는 키

암호화 (6) 공개키 암호화 (2) 장점 단점 RSA 디지털 서명 안전성과 편의성이 대폭 개선됨 메시지 내용 또는 발신에 대한 부인 방지를 위한 전자 서명 기능을 제공 단점 처리 속도가 느림 RSA 1977년 MIT의 Rivest, A. Shamir, L. Adelman이 개발 디지털 서명 A의 비공개키로 암호화하여 B에게 전송, B는 A의 공개키로 이를 해독 A의 공개키로 해독이 가능하다면 이 암호문은 A의 비공개키로 암호환 것임을 확신

DES (Data Encryption Standard)

DES (Data Encryption Standard) 특징 1977년 미 상무성의 국립 표준국(National Bureau of Standards)에서 연방표준 채택 64비트 블럭 암호 알고리즘 56bit : Key 8bit: Parity Check 기본 구조 round 수 : 16 round 복호화는 암호화의 역순 최근에는 DES암호화를 세 개의 키로 세 번 반복함으로써 암호의 강도를 높인 Triple-DES를 사용 치환과 전치 혼합방법, 블럭 암호, 관용암호방식

DES 알고리즘의 일반적 모형 처리 단계 평문 : 64bit 키 : 56bit + 8bit(parity) 초기 순열 단계 16라운드 반복 좌우 교환 역초기순열 단계

DES : : Li = Ri-1 Ri = Li-1 XOR f (Ri-1, Ki) 데이터 암호화 부 입 력 L16 R16 L0 초기 순열 L0 R0 K1 f R16 L16 L1 R1 K2 f 역초기 순열 : L2 R2 : 출 력 K16 L16 R16 Li = Ri-1 Ri = Li-1 XOR f (Ri-1, Ki)

5.3 DES

DES 초기 순열 IP (64 -> 64) 58 50 42 34 26 18 10 2 60 52 44 36 28 20 12 4 62 54 46 38 30 22 14 6 64 56 48 40 32 24 16 8 57 49 41 33 25 17 9 1 59 51 43 35 27 19 11 3 61 53 45 37 29 21 13 5 63 55 47 39 31 23 15 7 역초기 순열 IP-1 (64 -> 64) 초기 순열과 상호 역 성립

DES . . . . f함수 확장순열(E) 48bit K (48bit) S1 S2 S7 S8 S-box table 순열 P R(32bit) 확장순열(E) 48bit K (48bit) . . . . S1 S2 S7 S8 S-box table 순열 P 32 bit

DES 확장순열(E) (32->48) 순열 P (32->32) 32 1 2 3 4 5 4 5 6 7 8 9 32 1 2 3 4 5 4 5 6 7 8 9 8 9 10 11 12 13 12 13 14 15 16 17 16 17 18 19 20 21 20 21 22 23 24 25 24 25 26 27 28 29 28 29 30 31 32 1 16 7 20 21 29 12 28 17 1 15 23 26 5 18 31 10 2 8 24 14 32 27 3 9 19 13 30 6 22 11 4 25

DES S-box Table S1 14 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7 0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8 4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0 15 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13 예) 0 1 1 0 1 1 (6bit) 행 (1행) 열 (13열) ‘011011’를 4비트로 출력 : “0 1 0 1”

DES : Key 생성 키 c0 c1 c2 c15 d0 d1 d2 d15 K1 K2 K16 선택 순열-1 선택순열-2 좌측 시프트 c1 c2 c15 d0 d1 d2 d15 선택순열-2 K1 K2 K16 :

DES 순열선택1 (PC-1) 순열선택2 (PC-2) : 56->48 DES 키의 단계별 계산표 57 49 41 33 25 17 9 1 58 50 42 34 26 18 10 2 59 51 43 35 27 19 11 3 60 52 44 36 63 55 47 39 31 23 15 7 62 54 46 38 30 22 14 6 61 53 45 37 29 21 13 5 28 20 12 4 순열선택2 (PC-2) : 56->48 14 17 11 24 1 5 3 28 15 6 21 10 23 19 2 4 26 8 16 7 27 20 13 2 41 52 31 37 47 55 30 40 51 45 33 38 44 49 39 56 34 53 46 42 50 36 29 32

DES Key 쉬프트 스케줄 라운드 수 좌측 쉬프트 수 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

DES Attack 차분 암호 해독 (Differential Cryptanalysis) 247의 선택 평문을 가지고 247차수로 해독 선형 암호 해독 (Linear Cryptanalysis) 247 기지 평문으로 해독 가능 기지 평문이 선택 평문보다 구하기 쉽기만 DES공격으로서의 선형 암호 해독은 가능성이 없음 선형 암호 해독의 타당성 주장이 약함

Message Digest 5 미국 MIT의 로널드 리베스트 교수가 개발 MD5는 입력 데이터로부터 128bit의 메시지 축약을 만듦 데이터의 무결성을 검증 전자 서명 응용 프로그램에 사용할 목적으로 개발됨

Structure of md5

Figure 9-11. The 16 iterations during the first round in a phase in MD5.

Section 01 공개키 기반구조(PKI) 공개키 기반 구조의 개념 공개키 기반 구조(PKI, Public Key Infrastructure)는 메시지의 암호화 및 전자서명을 제공하는 복합적인 보안 시스템 환경. 공개키 기반 구조는‘인터넷에서 신분증을 검증해주는 관청’이라고 생각할 수 있음. 가장 가까운 관청이 동사무소고, 그 동사무소들 위에 구청이 있고, 그 구청위에 시청이 있고, 맨 위에 정부가 있는 것과 같음. 공개키 기반 구조하에 있는 사람은 어디에 가서도 자신의 인터넷상 신분을 CA와 공인인증서를 통해 증명할 수 있음. 여기서 CA가 일종의 동사무소고, 공인인증서가 주민등록증과 같은 신분증인 것.

Section 01 공개키 기반구조(PKI) 공개키 기반 구조가 되기 위해서는 인증 정보를 일원화하여 호환성을 갖추고 개인이 이를 쉽게 접근할 수 있어야 하는데, 이를 위해 앞서의 동사무소, 구청, 시청, 정부처럼 트리형의 공개키 기반 구조를 구성.

Section 01 공개키 기반구조(PKI) PAA(Policy Approval Authorities, 정책승인기관) : 공인인증서에 대한 정책을 결정하고 하위 기관의 정책을 승인하는 기관. 정보통신부가 담당. PCA(Policy Certification Authorities, 정책인증기관) : RootCA를 발급하고 기본 정책을 수립하는 기관. KISA(Korea Information Security Agency, 한국정보보호진흥원)가 여기에 해당. RootCA는 모든 인증서의 기초가 되는인증서를 보유하고 있으며, 인증서에 포함된 공개키에 대응되는 개인키를 이용해 생성한 자체 서명 인증서를 사용. CA (Certification Authoriy, 인증기관) : 인증서 발급과 취소 등의 실질적인 업무를 하는 기관. CA는 상호간 신뢰한다. yessign(금융 결제원), NCA(한국 전산원) 등이 있음. RA (Registration Authority, 등록기관) : 사용자의 신분을 확인하고 CA간 인터페이스를 제공.

Section 01 공개키 기반구조(PKI) 네트워크 구조 모델은 인증기관이 상호인증(crosscertification)을 통해 연결되어 있는 모델. 상호인증이란 두 인증기관이 상대방의 공개키를 서로 인증해주는 인증서를 발급하여 사용하는 경우로, 이 때의 인증서를 상호인증서(cross-certificate)라 함. 일반적으로는 계층 구조와 네트워크 구조를 혼합해 사용

공인인증서에 대한 이해 공인인증서 공인인증서의 저장 위치 공개키와 그것의 소유자를 연결시켜주는 전자문서며, 펠더(Kohnfelder)가 1978년에 처음 제안. 공인인증서는 신뢰할 수 있는 인증기관(CA)이 전자서명하여 생성. 오늘날 사용되는 대부분의 인증서는X.509 버전 3 표준을 따름. 이 표준 이외에도 SPKI(Simple Public Key Infrasturcture) 인증서, PGP(Pretty Good Privacy) 인증서가 있음. 공인인증서의 저장 위치 [그림 8-4] 인증서가 설치된 디렉토리

Section 02 전자 서명과 전자 봉투 전자서명 서명은 일종의 도장으로, 서명한 사람의 신분을 집약적으로 증명하는 것 계약을 할 때 사용하는 인감도장은 동사무소 등과 같은 공공기관에 등록하여 공증을 받은 것으로, 계약서 등의 날인에 사용. 전자서명이 인감도장이되고, 두 사람의 전자서명은 공인 인증기관에 등록되고 검증되어 사용.

Section 02 전자 서명과 전자 봉투 전자서명 전자서명에서는 원본의 해시값을 구한 뒤, 그 해시값에 부인방지 기능을 부여하기 위해 공개키 방법을 사용. 철수가 영희에게 편지를 보낼 때, 편지의 해시값을 구한 후 그 해시값을 자신의 사설키로 암호화하여 보냄.

Section 02 전자 서명과 전자 봉투 전자서명 영희는 철수의 공개키를 이용해 암호화된 해시값을 복호화하고, 원본 문서를 해시한 값과 비교. 복호화한 해시값과 전달된 편지에서 구한 해시값이 일치하면 전달된 편지가 철수로부터 온 것이 맞고 위조되지 않았음을 확신할 수 있음..

Section 02 전자 서명과 전자 봉투 전자서명이 제공하는 기능 국내의 전자서명 위조불가(Unforgeable): 서명자만이 서명문을 생성할 수 있음. 인증(Authentication): 서명문의 서명자를 확인할 수 있음. 재사용 불가(Not Reusable): 서명문의 해시값을 전자서명에 이용하므로 한 번 생성된 서명을 다른 문서의 서명으로 사용할 수 없음. 변경 불가(Unalterable): 서명된 문서는 내용을 변경할 수 없기 때문에 데이터가 변조되지 않았음을 보장하는 무결성(Integrity)을 만족함. 부인방지(Non Repudiation): 서명자가 나중에 서명한 사실을 부인할 수 없음. 전자서명에 관련해 미국에는 1994년에 만들어진 DSS(Digital Signature Standard)가 있고 이는 DSA(Digital Signature Algorithm)를 사용함. DSA는 슈노어(Schnorr)와 엘 가말(ElGamal)의 알고리즘을 기반으로 함. 서명 생성이나 암호키 생성에서는 SHA.1을 이용하고 있음. 국내의 전자서명 우리나라에서는 1996년에 개발된 KCDSA(Korean Certifice-based Digital Signature Algorithm)가 있음. 현재 우리나라의 전자서명법에 따르면, 전자서명은 인터넷을 통해 전자문서를 교환할 때 일반 문서에서 쓰이는 인감도장과 법적으로 똑같은 효력을 지님.

Section 02 전자 서명과 전자 봉투 전자봉투 전자봉투는 전달하고자 하는 메시지를 암호화하여 한 사람을 통해서 보내고, 암호화 키는 다른 사람에게 가져가게 하는 것을 암호학적으로 구현한 것. 철수는 전자봉투를 사용하기 위해 우선 전자서명을 생성하고 전자서명과 원문, 그리고 자신의 공개키가 들어있는 인증서를 비밀키(DES 알고리즘 등에 사용되는 대칭키)를 사용하여 암호화. 전자서명 세트와 인증서를 암호화한 비밀키를 영희의 공개키로 암호화하는데, 이것이 전자봉투가 됨. 철수는 최종적으로 비밀키로 암화화한 결과와 비밀키가 암호화된 전자봉투를 영희에게 보냄. 전자봉투는 앞서 살펴본 기밀성, 무결성, 부인방지를 모두 지원.

Section 02 전자 서명과 전자 봉투 전자봉투를 이용한 암호화 전송

Section 02 전자 서명과 전자 봉투 전자봉투의 복호화 전달받은 영희는 우선 전자봉투를 자신의 사설키로 복호화하여 비밀키를 획득. 비밀키를 이용하여 전자서명과 평문, 철수의 인증서를 복호화(해독). 그런 다음, 복호화한 인증서에서 철수의 공개키를 얻어 전자서명을 복호화한 후 이를 원문 해시 결과와 비교

Section 03 전자상거래-신용카드 결제 SET의 구성 SET(Secure Electronic Protocol) 1996년 비자(Visa)와 마스터(Master) 카드 회사의 합의에 의해 만들어진 프로토콜. SET의 구성 카드 사용자 : 신용카드를 소지한 사람으로 SET에 이용되는 인증서를 소유. 상점: 인터넷 쇼핑몰을 운영하며 SET를 이용하여 상품을 판매. 지불 게이트웨이(PG, Payment Gateway): 기존의 신용카드 지불 방식으로 은행과 거래 내역을 주고받음. 신용카드 회사(Issuer): 사용자에게 신용카드를 발급하고, CA를 운영하여 사용자에게 인증서를 발급. 은행(Acquirer): 상점의 계좌가 있으며 지불 게이트웨이를 운영. 또한 CA를 운영하며 상점에 인증서를 발급. 인증기관: SET에 참여하는 모든 구성원의 정당성을 보장하는 루트(Root) CA.

신용카드 결제 이중 서명 값 생성 이중 서명의 생성 : 카드 사용자가 구매정보와 지불정보를 각각 해시한 후, 두 해시값을 합한 뒤 다시 해시. 그리고 최종 해시값을 카드 사용자의 사설키로 암호화(서명). 이중 서명의 목적은 상점이 카드 사용자의 계좌번호 같은 지불정보를 모르게 하고, 상점에 대금을 지불하는 은행이 카드 사용자가 상점에서 산 물건이 무엇인지 모르면서 상점이 요구한 결제 대금이 정확한지 확인할 수 있게 하는 데 있음.

신용카드 결제 비밀키 생성 카드 사용자는 하나의 비밀키(대칭키)를 생성. 그리고 비밀키를 사용해 지불정보를 암호화하고, 비밀키는 은행이 운영하는 지불 게이트웨이의 공개키로 암호화.

신용카드 결제 결제를 위해 상점으로 데이터 전송

신용카드 결제 상점에서 구매정보 확인 카드 사용자로부터 위와 같은 정보를 받은 상점은 카드 사용자가 신청한 물건에 대한 구매정보 의 해시를 구하고(➊), 카드 사용자가 보내온 한 쌍의 해시값을 새로 구한 해시로 대치시킨 뒤(➋), 새로운 이중 해시를 구함(➌). 그리고 이 카드 사용자의 사설키로 암호화된해시값을 복호화하여(➍) 이를 새로 구한 이중 해시값과 비교(➎). 그런 다음, 카드 사용자가 보내온 구매정보가 그 카드 사용자의 것인지 또는 구매정보가 변조되지 않았는지 확인.

신용카드 결제 상점에서 지불게이트웨이로 지불정보 전송

신용카드 결제 지불정보의 확인 지불 게이트웨이는 자신의 사설키로 비밀키를 복호화하여 지불정보를 확인. 그리고 상점이 한 것처럼 받은 지불정보를 해시한 값으로 한 쌍의 해시값을 대치하여 이중 해시값을 비교하고, 지불정보의 변조 여부를 확인한 뒤 상점에 대금을 지불.

신용카드 결제 Cyber Cash 1995년부터 서비스하고 있고 미국에서 80%의 은행이 가입되어 있지만, 세계적으로 널리 쓰이지 않음. 고객이 웹 브라우저를 이용해 해당 상점에 구입 의사를 표시하고 해당 물건에 대한 <지불>버튼을 누르면 웹 브라우저가 자동으로 Cyber Cash의 소프트웨어를 실행시킴. 소비자는 이 소프트웨어에서 어떤 신용카드로 대금을 지불할 것인지 선택한 후 <확인> 버튼을 눌러 판매자에게 주문 및 결제 정보를 보냄. 이 때 소프트웨어는 결제 정보를 암호화하여 전송. 판매자는 결제 정보에 확인 정보를 추가하고 사설키로 암호화한 후 이를 Cyber Cash 서버에 보냄. 이 때 판매자는 SET처럼 고객의 신용카드 정보를 볼 수 없음. 서버에서는 구매자와 판매자의 신원을 확인 후 거래를 처리하며, 처리한 정보를 은행에 보냄. 현재 국내의 상당수 신용카드 결제 시스템이 이와 비슷하게 동작. SET와 달리 Cyber Cash에서는 지불 게이트웨이 역할을 하는 Cyber Cash 서 버가 고객이 어떤 물건을 구입했는지에 대한 정보를 알게 된다는 문제점이 있음.

신용카드 결제 First Virtual 전자상거래에서의 메시지 전달을 통해 거래 정보를 교환. 이러한 메시지 전달은 모두 이메일(전자우편), 즉 SMTP 프로토콜로 이루어지고 있음. 고객이 상점에 물건을 구입할 의사를 밝히면 상점은 서버에 대금의 지불을 요구하는 전송- 요청(transferrequest) 메시지를 전송하고, 서버는 고객에게 전송-질의(transfer-query) 메시지를 전송. 그러면 고객은 구매 확인 이메일을 받게 되고, 이 이메일에 회신을 보냄으로써 구매의 절차가 완료. 전달되는 이메일에는 Yes/No/Fraud/Help 중 한 가지를 꼭 선택하도록 되어 있음. Yes는 구매 확인을, No는 구매 취소를 의미함. 그리고 Fraud는 이런 구매를 한 적이 없음을 의미하는데, 이 경우는 누군가 나의 ID를 도용한 것이므로 서버가 해당 ID를 즉시 취소하고 그 고객에게 새로운 ID를 부여. First Virtual은 신뢰도가 낮은 편이라 100달러 이하의 거래에 이용되고 있음.

전자화폐 ECash ECash는 네덜란드의 디지캐시(DishCash)가 개발한 전자화폐 시스템으로, 1994년 10월부터 서비스. 고객이 ECash 클라이언트 소프트웨어(이하ECash 클라이언트)를 이용해 은행에서 ECash를 인출해 자신의 컴퓨터에 저장. 그리고 ECash를 이용할 수 있는 상점에서 물건을 구매하고 ECash를 이용해 대금을 지불. 이 때 고객은 은행계좌나 신용카드 번호를 사용할 필요가 없음. 상점은 받은 ECash를 은행에서 현금으로 바로 바꿀 수 있고 지불된 ECash를 고객이 다시 사용할 수 없도록 데이터베이스에 등록. ECash는 현금과 같은 익명성을 보장받을 수 있고, 인가된 상점간의 거래뿐만 아니라 사용자간의 화폐 이동도 가능하다는 장점이 있음. 그러나 ECash의 1회 이용 비용 때문에 상점은 어느 정도의 수수료를 부담해야 함. 또한 ECash의 잘못된 사용을 되돌리기가 무척 어려움. 네트워크가 불안하거나 데이터 전송 중 잘못된 간섭 현상이 발생하면 이에 대한 수정이 불가능함. Mondex Mondex는 버스 카드와 유사. IC 칩이 들어간 스마트 카드를 사용하고, 카드에 일정액을 입력한 뒤 사용. [그림 8-19] Mondex 카드에 들어가는 IC 칩

워터마크와 스테가노그래피 워터마크 스테가노그래피 워터마크는 편지지의 제작사를 표시하기 위해 편지지에 투명무늬를 희미하게 프린트한 것을 워터마크라고 부른데서 시작. 종이로 출력해 판매되는 IT 관련 문서의 페이지 전체에 옅은 색으로 소유권을 가진 회사의 로고를 표시한 것이 이에 해당. 영상이나 오디오 파일에도 이런 데이터를 삽입. 워터마크는 저작물의 사용자가 알아볼 수 있게 표시되기도 하지만 해당 저작물이 조작되지 않도록 인지할 수 없는 방식으로 표시되기도 함. 스테가노그래피 미리 정해진 약속을 통해 원래의 것과는 전혀 관련없는 데이터를 약속에 맞춰 이용하여 은밀한 정보를 전달함

Section 04 전자 우편 (이메일) PGP(Pretty Good Privacy) 필 치머만(Phil Zimmermann)이 독자적으로 개발 PGP를 사용하는 사람들끼리의 신뢰 관계를 통해 인증. 철수가 영희, 민수와 PGP를 통해 서로 신뢰하는 관계라면, 영희와 민수도 철수를 통해 서로를 신뢰하게 됨. 이는 공인인증서에서 살펴본 상호인증서를 통한 네트워크 구조와 유사. PGP는 이런 상호인증을 통해 많은 인터넷 사용자가 서로를 인증하여 그물망과 같은 인증구조를 가지게 됨. [그림 8-20] 필 치머만

Section 04 전자 우편 (이메일) S/MIME S/MIME(Secure MIME)은 인증서 서비스를 통하여 암호화되는 메일 서비스를 제공. S/MIME 관련 프로그램을 설치하면 대부분 자동으로 이루어짐. S/MIME은 아직까지 널리 쓰이지 않으나 회사에서 그룹웨어를 사용할 때 이와 매우 비슷한 형태의 암호화 메일을 제공하는 경우가 많음.