Chapter 09. 암호를 이용한 전자상거래 : 상거래를 사이버 세계로 끌어들인 암호

전자상거래에 대한 이해 공개키 기반 구조 전자서명과 전자봉투 전자결재 암호화 통신 컨텐츠 보안

전자상거래의 보안 요구 사항을 이해한다. 공개키 기반기술의 원리를 이해한다. 공인인증서에 대해 알아본다. 전자상거래에서 이용되는 암호화와 해시 기술을 이해한다. PGP를 이용하여 암호화된 메일을 살펴본다. IPSEC와 SSL에 대해 알아본다.

01 전자상거래에 대한 이해 전자상거래의 시작 1979년 : 마이클 알드리치(Michael Aldrich)는 전화선을 이용해 통신하도록 개조된 TV로 최초의 온라인 쇼핑을 가능하게 함. 비디오텍스는 1970년대부터 1980년 중반까지 주로 온라인 홈뱅킹에 사용됨. 1981년 : 비디오텍스를 이용하여 씨티뱅크(Citibank), 체이스 맨하탄 (Chase Manhattan), 케미컬(Chemical), 메뉴팩쳐러스 하노버(Manufacturers Hanover)가 뉴욕에서 서비스를 제공하기 시작 1994년 : 본격적인 전자상거래의 시작 처음으로 피자헛(Pizza Hut)이 웹 페이지를 통해 주문을 받음. 최초의 인터넷을 통한 온라인 서비스를 제공하는 은행(스탠다드 연방 신용 연합, Stanford Federal Credit Union)이 문을 열었으며 코드 네임 모질라(Mozilla)로 넷스케이프(Netscape) 1.0이 만들어짐. 넷스케이프는 SSL 암호화를 통해 안전한 거래를 제공했다. 1995년 : 월 스트리트의 컴퓨터 시스템 전문가였던 제프 베조스(Jeff Bezos)가 인터넷 가상 상점인 아마존 (Amazon)을 설립 [그림 9-1] 비디오텍스 [그림 9-3] 제프 베조스 [그림 9-4] 1994년 아마존 사이트

01 전자상거래에 대한 이해 전자상거래의 보안 요건 전자상거래가 성공하기 위한 조건 전자상거래에서는 원격의 거래 상대를 신뢰하기 어려우므로 네트워크상에서 상대방 및 자신에 대한 신분 확 인 수단이 필요 전자상거래에서는 거래 사실(거래 내역)의 공증을 보장할 수 있는 신뢰할 만한 제3자의 중재가 필요 전자상거래에서는 전자지불 방식(과정)의 안정성을 보장하기 위한 방법이 확보되어야 함. [표 9-1] 전자상거래의 보안 공격 유형 공격 유형 설명 인증에 대한 공격 네트워크를 통해 접근한 사용자가 적절하지 못한 인증을 통해 다른 사용자로 위장하는 것 예) 최근 가짜 은행 사이트를 만들어 은행 사용자에 대한 공인인증서 정보를 획득하여 악용 하는 사례 등 송·수신 부인 공격 네트워크를 통해 수행한 인증 및 거래 내역에 대해 부인하는 것 예) 계좌이체 및 신용카드 지불을 받고도 받지 않았다고 부인하거나, 소매점으로부터 상품을 받은 후 받지 않았다고 부인하는 사례 등 기밀성에 대한 공격 네트워크를 통해 전달되는 인증 정보 및 주요 거래 정보가 유출되는 것 예) 전자 결제 시 카드 번호 정보가 유출되어 부정 사용되는 사례 등 무결성에 대한 공격 네트워크의 도중에 거래 정보 등이 변조되는 것 예) 온라인 계좌이체 등을 이용한 전자 결제 시 수신 계좌나 금액 등을 변조하는 사례 등

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

02 공개키 기반 구조 공개키 기반 구조의 개념 공개키 기반 구조가 되기 위해서는 인증 정보를 일원화하여 호환성을 갖추고 있어야 하고 개인이 이를 쉽게 접 근할 수 있어야 함. 이를 위해 앞서 이야기한 동사무소, 구청, 시청, 정부와 같은 트리형 구조가 필요 [그림 9-6] 공인인증서 운영을 위한 계층 구조

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

02 공개키 기반 구조 공개키 기반 구조의 개념 네트워크 구조 모델은 인증기관이 상호인증(crosscertification)을 통해 연결되어 있는 모델 상호인증이란 두 인증기관이 상대방의 공개키를 서로 인증해주는 인증서를 발급하여 사용하는 것 이때 인증서를 상호인증서(cross-certificate)라 함. 일반적으로는 계층 구조와 네트워크 구조를 혼합해 사용 [그림 9-7] 국가와 기관 간 상호인증 구조

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

02 공개키 기반 구조 공인인증서에 대한 이해 인증서가 가지는 정보 인증서의 기본 영역 버전 : 인증서의 형식 구분(우리가 사용하는 대부분의 공인인증서는 버전3) 일련번호 : 인증서를 발급한 인증기관 내의 인증서 일련번호 서명 알고리즘 : 인증서를 발급할 때 사용한 알고리즘 발급자 : 인증서를 발급한 인증기관의 DN(Distinguish Name) 유효 기간(시작, 끝) : 인증서를 사용할 수 있는 기간(시작일과 만료일을 기록하며 초 단위까지 표기됨). 주체 : 인증서 소유자의 DN 공개키 : 인증서의 모든 영역을 해시해서 인증기관의 개인키로 서명한 값 [그림 9-9] 인증서 내용 열람

02 공개키 기반 구조 공인인증서에 대한 이해 인증서의 확장 영역 기관 키 식별자 : 인증서를 확인할 때 사용할 인증기관 공개키의 유일 식별자 주체 키 식별자 : 인증서 소유자의 공개키에 대한 유일 식별자 주체 대체 이름 : 인증서 사용자의 이름 혹은 또 다른 별개의 이름에 대한 부가 정보로 사용자 ID, E-mail, IP 주소, DNS 이름 등을 표시(버전3에서는 x.500DN 이외에 하나의 대체 이름을 가질 수 있음) CRL 배포 지점 : 인증서의 폐기 여부를 확인하기 위한 인증서 폐기 목록(CRL)이 있는 위치 기관 정보 액세스 키 사용 용도 : 인증서에 포함된 공개키의 용도를 나타냄 인증서 정책 손도장 알고리즘 손도장 인증서의 특성 누구나 사용자의 인증서를 획득하고, 공개키를 획득할 수 있음. 인증기관 이외에는 인증서를 수정/발급할 수 없음. 같은 인증 구조 내의 사용자는 상호인증서 신뢰가 가능

02 공개키 기반 구조 공인인증서에 대한 이해 인증서의 폐기 폐기된 인증서의 사용에 따른 피해를 줄임. 폐기된 인증서의 사용에 따른 피해를 줄이기 위해 인증기관은 폐기된 인증서 목록을 주기적으로 발급. 이를 인증서 폐기 목록(CRL, Certification Revocation List)이라 함. (X.509 표준에 정의되어 있음) 이 목록도 인증서처럼 임의로 조작하거나 만들 수 없어야 함. 따라서 인증서처럼 인증기관이 전자서명을 하여 발급 인증서 폐기 목록은 보통 폐기된 인증서에 관한 정보만 유지 이와 같은 접근 방법을 나쁜 목록(bad-list) 방법이라 함. 반대로 좋은 목록(good-list) 방법도 있음. 좋은 목록에서는 이 목록에 포함된 인증서만 사용 나쁜 목록에서는 이 목록에 포함되지 않은 인증서만 사용해야 함.

03 전자서명과 전자봉투 전자서명 서명이란 서명한 사람의 신분을 집약적으로 증명하는 도구로 전자서명도 이와 비슷 우리나라의 전자서명법의 정의 : 전자서명이란 서명자가 해당 전자문서에 서명하였음을 나타내기 위해 전자문 서에 첨부되거나 논리적으로 결합된 전자적 형태의 정보를 말한다. 계약을 할 때 사용하는 인감도장은 동사무소 등과 같은 공공기관에 등록하여 공증을 받은 것으로, 계약서 등의 날인에 사용. 전자서명이 인감도장이 되고, 두 사람의 전자서명은 공인 인증기관에 등록되고 검증되어 사용. [그림 9-10] 인감도장을 사용한 계약서 날인 [그림 9-11] 전자서명을 사용한 인증

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

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

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

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

03 전자서명과 전자봉투 전자봉투 전달받은 영희는 우선 전자봉투를 자신의 사설키로 복호화하여 비밀키를 획득 비밀키를 이용하여 전자서명과 평문, 철수의 인증서를 복호화(해독) 복호화한 인증서에서 철수의 공개키를 얻어 전자서명을 복호화한 후 이를 원문 해시 결과와 비교 전자봉투는 기밀성, 무결성, 부인 방지를 모두 지원함. [그림 9-15] 전자봉투의 복호화

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

04 전자결재 SET SET의 지불 과정 이중 서명의 생성 이중 서명의 목적 카드 사용자가 구매정보와 지불정보를 각각 해시 두 해시값을 합한 뒤 다시 해시 최종 해시값을 카드 사용자의 사설키로 암호화(서명) 이중 서명의 목적 상점이 카드 사용자의 계좌번호 같은 지불정보를 모르게 함. 상점에 대금을 지불하는 은행이 카드 사용자가 상점에서 산 물건이 무엇인지 모르면서 상점이 요구한 결제 대금이 정확한지 확인할 수 있게 하는 데 있음. [그림 9-17] 이중 서명의 기본 동작

04 전자결재 SET SET의 지불 과정 비밀키(대칭키) 생성 결제를 위한 데이터 전송 비밀키를 사용해 지불정보를 암호화하고, 비밀키는 은행이 운영하는 지불 게이트웨이의 공개키로 암호화. 결제를 위한 데이터 전송 [그림 9-18] 비밀키의 생성 [그림 9-19] 결제를 위해 카드 사용자가 상점에 전송하는 데이터

04 전자결재 SET SET의 지불 과정 카드 사용자로부터 구매정보 확인 상점은 카드 사용자가 신청한 물건에 대한 구매정보의 해시를 구하고(), 카드 사용자가 보내온 한 쌍의 해 시값을 새로 구한 해시로 대치시킨 뒤(), 새로운 이중 해시를 구함(). 그 후 카드 사용자의 사설키로 암호 화된 해시값을 복호화하여() 이를 새로 구한 이중 해시값과 비교() 그런 다음 카드 사용자가 보내온 구매정보가 그 카드 사용자의 것인지 또는 구매정보가 변조되지 않았는지 확인 [그림 9-20] 이중 해시값을 이용한 구매정보 확인

04 전자결재 SET SET의 지불 과정 상점은 지불 게이트웨이로 지불 정보 전송 [그림 9-21] 상점이 지불 게이트웨이로 보내는 데이터

04 전자결재 SET SET의 지불 과정 지불 정보 확인 지불 게이트웨이는 자신의 사설키로 비밀키를 복호화하여 지불정보를 확인 상점이 한 것처럼 받은 지불정보를 해시한 값으로 한 쌍의 해시값을 대치하여 이중 해시값을 비교하고, 지불정보의 변조 여부를 확인한 뒤 상점에 대금을 지불. [그림 9-22] 지불정보의 확인

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

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

04 전자결재 스마트카드 접촉식 카드 접촉식 스마트카드 리더기와 스마트카드의 접촉부(CHIP) 사이의 물리적 접촉에 의해 작동하는 스마트카드 접촉식 카드는 접점의 잦은 접촉으로 인해 전기적 충격이나 손상이 생길 우려가 있음. 보안이 중요한 많은 DATA를 처리하는 거래 인증, 전자서명 등의 응용에 적합 비접촉식 카드 구리선을 이용하여 무선 주파수 파장을 전력으로 전환하는 방식으로 구동시켜 스마트카드 리더기와 통신하 는 카드 처리 시간에 제한을 받는 교통, 유통 등에 적합 [그림 9-24] 접촉식 카드의 구조 [그림 9-25] 비접촉식 카드의 구조

04 전자결재 스마트카드 하이브리드 카드 하나의 카드 안에 접촉식 카드와 비접촉식 카드가 별도로 존재하는 하이브리드(Hybrid) 형식의 카드 하드웨어와 소프트웨어 역시 별도로 존재 콤비 카드 접촉식 카드와 비접촉식 카드가 공유할 수 있는 부분을 상호 공유하는 스마트카드 [그림 9-26] 하이브리드 카드의 구조 [그림 9-27] 콤비 카드의 구조

04 전자결재 스마트 카드 SIM 카드 가입자 식별 모듈(Subscriber Identification Module)을 구현한 IC 카드 GSM 단말기의 필수 요소 3세대 이동통신 단말기에서는 USIM(Universal Subscriber Identity Module, 범용 사용자 식별 모듈)으로 표준 이 확장됨. 4세대 이동통신인 LTE에서도 일부 수정되어 사용되고 있음. [그림 9-28] USIM

04 전자결재 스마트카드 정적 데이터 인증 정적 데이터를 이용하여 매회 인증할 때마다 같은 데이터를 사용 [그림 9-29] 정적 데이터 인증 카드의 발행

04 전자결재 스마트카드 정적 데이터 인증 정적 응용 프로그램 데이터 : 카드 번호, 사용자 이름, 주소 등의 값을 설정 서명된 정적 응용 프로그램 데이터 : 발행기관의 개인키를 이용하여 에서 설정한 정적 응용 프로그램 데이 터를 서명(암호화)함. 인증기관(CA)의 개인키로 발행자의 공개키를 암호화함. 인증 데이터 저장 : 서명된 정적 응용 프로그램 데이터와 인증기관(CA)의 개인키로 발행자의 공개키를 암호 화한 데이터를 스마트카드에 저장 인증기관(CA)의 공개키를 스마트카드 단말에 배포

04 전자결재 스마트카드 정적 데이터 인증 발행된 스마트카드는 카드 단말에 의해 그 진위 여부가 확인됨. 인증기관(CA)의 개인키로 암호화된 발행기관의 공개키가 전달됨. 전달된 발행기관의 공개키는 카드 단말기에 저장된 인증기관의 공개키로 복호화됨. 복호화된 인증기관의 공개키로 스마트카드에 저장된 ‘서명된 정적 응용 프로그램 데이터’를 복호화하여 카드 단말 기는 ‘정적 응용 프로그램 데이터’를 확인함. [그림 9-30] 정적 데이터 인증 카드 인증

04 전자결재 스마트카드 동적 데이터 인증 변화되는 데이터를 이용하여 매회 인증할 때마다 다른 데이터를 사용 동적 데이터 인증은 보안 레벨이 높으며, IC 카드 측에서 암호 계산을 위해 암호화 코프로세서를 탑재 [그림 9-31] 동적 데이터 인증 카드의 발행

04 전자결재 스마트카드 동적 데이터 인증 정적 응용 프로그램 데이터 : 카드 번호, 사용자 이름, 주소 등의 값을 설정 정적 응용 프로그램 데이터와 스마트카드의 공개키 서명 : 발행기관의 개인키를 이용하여, 에서 설정한 정 적 응용 프로그램 데이터와 스마트카드의 공개키를 서명(암호화)함. 인증기관(CA)의 개인키로 발행자의 공개키를 암호화함. 인증데이터 저장 : 스마트카드의 개인기, 서명된 정적 응용 프로그램 데이터, 인증기관(CA)의 개인키로 발행 자의 공개키는 암호화한 데이터를 스마트카드에 저장 인증기관(CA)의 공개키를 스마트카드 단말에 배포

04 전자결재 스마트카드 동적 데이터 인증 진위 여부 확인 카드 단말은 스마트카드에 임의로 생성한 난수와 기타 동적 데이터를 생성하여 스마트카드에 전송 스마트카드는 본인의 스마트카드 개인키를 사용하여, 에서 전달받은 데이터와 기타 응용 프로그램 데이터를 서명 (암호화)하여 카드 단말에 전달 인증기관(CA)의 개인키로 암호화된 발행기관의 공개키가 전달. 전달된 발행기관의 공개키는 단말에 저장된 인증기관의 공개키로 복호화 복호화된 인증기관의 공개키로 스마트카드에 저장된 ‘서명된 정적 응용 프로그램 데이터’를 복호화 카드 단말은 ‘정적 응용 프로그램 데이터’와 스마트카드의 공개키를 확인 에서 획득한 스마트카드의 공개키를 이용하여 에서 스마트카드로부터 전달받은 데이터를 복호화 스마트카드에서 전송한 데이터의 진위 여부를 확인하고 처리 [그림 9-32] 동적 데이터 인증 카드 인증

04 전자결재 스마트카드 스마트카드 인증 동적 데이터 인증 카드 단말은 스마트카드에 임의로 생성한 난수와 기타 동적 데이터를 생성하여 스마트카드에 전송한다. 스마트카드는 본인의 스마트카드 개인키를 사용하여, 에서 전달받은 데이터와 기타 응용 프로그램 데이터를 서명( 암호화)하여 카드 단말에 전달한다. 인증기관(CA)의 개인키로 암호화된 발행기관의 공개키가 전달된다. 전달된 발행기관의 공개키는 단말에 저장된 인 증기관의 공개키로 복호화된다. 복호화된 인증기관의 공개키로 스마트카드에 저장된 ‘서명된 정적 응용 프로그램 데이터’를 복호화하고 카드 단말 은 ‘정적 응용 프로그램 데이터’와 스마트카드의 공개키를 확인한다. 에서 획득한 스마트카드의 공개키를 이용하여 에서 스마트카드로부터 전달받은 데이터를 복호화하고 스마트카 드에서 전송한 데이터의 진위 여부를 확인하고 처리한다.

05 암호화 통신 전자우편의 암호화 PGP 필 치머만(Phil Zimmermann)이 독자적으로 개발 서로를 신뢰하게 됨. 이는 공인인증서에서 살펴본 상호인증서를 통한 네트워크 구조와 유사. PGP는 이런 상호인증을 통해 많은 인터넷 사용자가 서로를 인증하여 그물망과 같은 인증구조를 가지게 됨. [그림 9-33] 필 치머만 [그림 9-34] PGP 상호인증 예 [그림 9-35] 인터넷에서의 PGP 상호인증

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

05 암호화 통신 전자우편의 암호화 PEM IETF(Internet Engineering Task Force)에서 채택 높은 보안성을 가지고 있음. 하지만 구현의 복잡성 등의 이유로 널리 쓰이지는 않음.

05 암호화 통신 네트워크 암호화 [그림 9-37] OSI 계층별 암호화 프로토콜

05 암호화 통신 네트워크 암호화 데이터 링크 계층의 암호화 프로토콜 PPTP L2TP 마이크로소프트가 제안한 VPN 프로토콜로, PPP(Point-to-Point Protocol)에 기초. PPP는 두 대의 컴퓨터가 직렬 인터페이스를 이용하여 통신할 때 사용 특히 전화선을 통해 서버에 연결하는 PC에서 자주 사용됨. L2TP 시스코가 제안한 L2F(Layer 2 Forwarding)와 PPTP가 결합된 프로토콜 PPTP와 L2TP는 모두 PPP 트래픽을 암호화 IP, IPX,NetBEUI, AppleTalk 등의 다양한 상위 로컬 네트워크 프로토콜을 사용할 수 있음. 둘다 사용자 인증(PAP, CHAP, MS-CHAP,EAP)이나 데이터 암호화/압축(CCP, ECP) 등의 보안 기능을 PPP에서 제공하 는 것을 사용. [표 9-2] PPTP와 L2TP 프로토콜의 비교 PPTP L2TP 네트워크 통신하기 위해 양단의 네트워크가 IP를 기반으로 해야 한다. 프레임 릴레이(Frame Realy), ATM 등에서도 사용할 수 있다. 터널링 두 시스템 사이에 하나의 터널만 지원한다. 여러 개의 터널을 허용하여 QoS(Quality of Service)에 따라 서로 다른 터널을 이용할 수 있다. 압축 및 인증 해당 기능 없다. 헤더 압축 및 터널에 대한 인증 기능을 제공한다.

05 암호화 통신 네트워크 암호화 네트워크 계층의 암호화 프로토콜 IPSec 3계층의 암호화 프로토콜 주요 기능은 AH (Authentication Header)를 이용한 인증, ESP(Encapsulation Security Payload)를 이용한 기밀성, IKE(Internet Key Exchange)를 이용한 비밀키 교환임. [표 9-3] IPSec 프로토콜의 기능 기능 특징 AH(Authentication Header) •전송 도중에 데이터가 변조되었는지 확인할 수 있도록 데이터의 무결성을 검사한다. • 데이터를 스니핑한 뒤 해당 데이터를 다시 보내는 재생 공격(Replay Attack)을 막을 수 있다. ESP(Encapsulating Security Payload) •메시지의 암호화를 제공한다. • ESP에서 사용하는 암호화 알고리즘으로는 DESCBC, 3DES, RC5, IDEA, 3IDEA, CAST, blowfish가 있다. IKE(Internet Key Exchange) • ISAKMP(Internet Security Association and Key Management Protocol), SKEME, Oakley 알고리즘의 조합으로, 두 컴퓨터 간의 보안 연결(SA: Seucrity Association)을 설정한다. • IPSec에서는 IKE를 이용하여 연결이 성공하면 8시간 동안 SA를 유지하므로, 8시간이 넘으면 SA를 다시 설정해야 한다.

05 암호화 통신 네트워크 암호화 전송 계층의 암호화 프로토콜 SSL 넷스케이프가 개발 40비트와 128비트의 키를 가진 암호화 통신을 할 수 있게 해줌. L2TP나 IPSec보다 상위 수준에서 암호화 통신기능을 제공 보통 4계층(전송 계층)과 5계층(세션 계층) 사이의 프로토콜이라 함. SSL의 기능은 크게 서버 인증, 클라이언트 인증, 암호화 세션임. 암호화된 통신은 40비트와 128비트의 암호화 세션을 형성 국내의 많은 사이트가 아직 40비트 암호화를 제공하는 모듈을 사용 서버 인증은 클라이언트가 자신이 신뢰할만한 서버에 접속을 시도하고 있는지를 확인하는 클라이언트가 공개키 기술을 이용하여 서버의 인증 서가 신뢰된 CA에서 발행된 것인지를 확인 서버는 클라이언트의 인증서를 확인하여 클라언트가 서버에 접속할 자 격이 있는지를 확인할 수 있음. [그림 9-38] OSI에서의 SSL의 동작 위치

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