[정보보안기사] 애플리케이션 보안 - 전자상거래 보안
- 목차 -
2. 전자상거래 보안
(1) 전자상거래 보안
① 전자상거래 구성요소
② 지불게이트웨이
③ SET Secure Electronic Transaction프로토콜
④ SSL Secure Socket Layer 프로토콜
⑤ OTP(One Time Password)
(2) 전자상거래 프로토콜
① 전자지불 방식별 특징
② 전자지불 화폐 프로토콜
③ 전자화폐의 요구조건
④ 전자화폐의 안정성 및 요구 사항
⑤ 전자입찰 프로토콜
⑥ 전자투표 프로토콜
(3) 무선 플랫폼에서의 전자상거래 보안
① 무선플랫폼에서의 전자상거래 보안
(4) 전자상거래 응용보안
① e-biz를 위한 ebXML e-business using XML 보안
2. 전자상거래 보안
(1) 전자상거래 보안
① 전자상거래 구성요소
▶ 고객, 상점, 은행, 인증기간 등 대표적인 4개의 참여 주체가 있다
② 지불게이트웨이 Payment Gateway(지불게이트웨이/지불중계기관)
▶ 가맹점 및 다양한 금융시스템의 거래 사이에서 중재자 역할을 하는 서비스
▶ SET에서는 판매자가 요청한 고객의 카드정보로, 금융기관에 승인 및 결재를 요청하는 자로 쓰임
③ SET Secure Electronic Transaction 프로토콜
▶ VISA와 Master Card에서 공동 개발한 신용카드 기반의 전자지불 프로토콜
Ⅰ. 특징
ⓐ 현재 쓰이고 있진 않지만, 신용카드 지불 시스템의 기반이 됨
ⓑ 너무 복잡하고 RSA, 알고리즘이 전체적인 속도를 저하 시킴
ⓒ 고객이 전자지갑 S/W를 설치해야 함
ⓓ 상점 또한 별도의 S/W를 설치해야 함
ⓔ 고객(카드소지자)와 상인(상점)에 대한 인증
ⓕ 지불 정보에 대한 비밀성 / 무결성 / 부인방지 기능
ⓖ 지불시스템에 대한 기술 표준
Ⅱ. 구성 요소
ⓐ 고객(Customer/Card Holder)
ⓑ 상점(Merchant)
ⓒ 지불중계관(Payment Gateway) - 판매자가 고객의 지불 정보로 금융기관에 승인 및 결재를 요청하는 자
ⓓ 발급사(Issuer) - 고객의 계좌를 개설하고 카드를 발행하는 금융기관
ⓔ 매입사(Acquirer) - 상점을 가맹점으로 승인하고 상점 계좌가 개설된 금융기관
ⓕ 인증기관(CA) : 참여 기관에게 전자적인 인증서를 발급하는 기관
Ⅲ. SET의 동작과정
1) 상점과 지불게이트웨이, 금융기관은 인증기관으로부터 인증서를 발급받음
2) 고객이 상점의 웹 사이트에서 물건을 고르고 결재를 위해 전자지갑 S/W를 다운받고 실행함
3) 전자지갑에 자신의 신용카드를 등록하고 인증기관으로부터 인증서를 발급받고 결재를 함
4) 전자지갑을 통해 결재정보가 상점으로 감
5) 상점에서 지불게이트웨이로 결재정보를 넘겨줌(상점은 주문정보만 확인함 ; 이중서명)
6) 지불게이트웨이는 결재정보를 금융기관에 전달
7) 금융기관이 상점에 대금 결제를 함
8) 상점은 고객에게 상품을 줌
9) 금융기관이 고객에게 나중에 돈을 요구
Ⅳ. SET에서의 암호화
▶ 전자봉투(Digital Envelope)
▷ 송신자의 전자문서에 암호화를 사용한 비밀키를 수신자만이 볼 수 있도록 수신자의 공개키로 암호화한 것
▷ 전자서명에 대칭키 암호화를 넣어 기밀성 까지 얻는 방식
- 전자서명 : 문서의 해시값을 송신자의 사설키로 암호화해서 문서, 공개키와 함께 보냄
- 대칭키 암호화(DES) + 공개키 암호화(RSA) + 전자서명(RSA) + 해쉬 함수(SHA-1)
▶ 이중 서명(Dual Signature)
▷ 주문정보와 지불정보를 각각 해쉬하여 만든 후 이것을 다시 합쳐 해쉬하고 전자서명하는 것
④ SSL Secure Socket Layer 프로토콜
▶ 인터넷을 통한 메시지 전송을 안전하게 하기 위해, Netscape에서 개발한 암호화 통신 프로토콜
▶ TCP 계층과 HTTP, LDAP, IMAP과 같은 응용계층 사이에서 동작한다
▶ 주로 HTTP와 같이 쓰이며, 이 경우에 SSL-enabled HTTP를 표시하기 위해 HTTPS라고 표기함
▶ SSL 3.0에 대한 수정 보완을 거쳐 TLS(Transparent Layer Security)라는 이름으로 표준화
▶ 암호화 통신을 위한 세션키 생성을 위해 인증서 기반의 공개키 알고리즘을 이용
Ⅰ. SSL의 기능 : 사이트 인증(Site Authentication) / 데이터 기밀성 / 메시지 무결성 (※ 부인방지는 없어)
Ⅱ. SSL Handshake Protocol
▶ 서버와 클라이언트 사이의 인증 / 암호화 알고리즘, 암호키, 무결성 알고리즘 등의 보안 협상
Ⅲ. SSL 버전별 비교
ⓐ SSL 2.0
- MITM 공격에 매우 취약 / 취약한 MAC / 수출용은 40bit Key
- 연결 초기에만 Handshake 가능
ⓑ SSL 3.0
- 해시값으로 메시지를 유지하며 MITM 방어 가능 / 수정한 MAC 사용 / 수출용은 128bit Key
- 연결 이후에도 Handshake 가능
ⓒ TLS 1.0은 SSL 3.1과 같음
⑤ OTP(One Time Password)
▶ 무작위로 생성되는 난수의 일회용 패스워드를 이용하는 사용자 인증방식
▶ 원격 사용자 인증시 패스워드의 재사용 공격을 사전에 방어하기 위한 방법
Ⅰ. OTP 생성 원리
1) 연계 정보 생성 : 시간, 이벤트 정보 등의 난수를 이용해 연계 정보를 생성
- 정보를 수집할 때마다, 다른 정보를 수집할 수 있어야 함
- 특정한 조건에서 생성되는 연계 정보는 동일해야 함(인증서버와 동일한 값 얻기 위해서)
2) 생성 알고리즘 : 연계 정보를 생성알고리즘을 통해 암호문을 생성함
- 동일한 연계 정보로 부터 동일한 암호문 생성해야 함
3) 추출 알고리즘 : 암호문에서 일회용 패스워드를 추출함
- 동일한 암호문으로부터 동일한 일회용 패스워드 추출해야 함
- 정적 추출 알고리즘 / 동적 추출 알고리즘
Ⅱ. OTP 구현 방식에 따른 분류
(2) 전자상거래 프로토콜
① 전자지불 방식별 특징
Ⅰ. 전자 지불 시스템
▶ 전자지갑, 신용카드, 전자화폐, 인터넷 뱅킹 등을 이용해 전자상거래에서 발생하는 구매 대금을 안전하고 효과적으로 지불, 결재하는 시스템
Ⅱ. 지불브로커(Payment Broker) 시스템
▶ 독립적인 신용구조 없이 신용카드나 은행계좌를 이용한 전자적 지불 수단
▶ 신용카드나 은행계좌 정보등을 지불브로커에 등록하고 거래가 성립될 때 대신 지불을 처리
(단점) 현실적인 전자지불 시스템이지만, 사용자의 거래 추적 가능성으로 프라버시 침해의 우려와 기밀정보의 노출 위험성이 있음
Ⅲ. 전자화폐(Electronic Cash) 시스템
▶ IC카드형-Mondex, E-Cash, Milicent, Net Cash, Proton 등
(장점) 사용자의 프라이버시를 보호 / 기밀정보의 노출 위험성의 제거 / 실제 화폐를 대치할 수 있다
(단점) 몇 가지 이론적인 문제좀도 남아 있다, 전자화폐 시스템을 지원할 수 있는 H/W기술이 부족하다
② 전자지불 화폐 프로토콜
Ⅰ. 전자 화폐 : 은행의 전자서명을 수행한 화폐가치를 가지는 디지털 데이터
▶ 독립적인 신용 구조를 가지며 거래 시 제3기관으로 부터 거래 승인이 없다
Ⅱ. 전자 화폐의 분류
▶ 후불형 : 거래가 이루어지고 난 후, 그 시점에 은행 계좌로 부터 인출되는 방식
▶ 선불형 : 거래가 이루어지기 전에, 미리 은행 계좌에서 인출해 거래가 일어나면 지불
Ⅲ. 거래 방식에 따른 분류
▶ IC카드형 - 온라인 오프라인 모두 사용 가능, IC카드에 화폐가치를 저장함
ex) Mondex, Visa Cash, PC pay
- 기술개발과 이용이 활발한 유럽에서 활성화
▶ 네트워크형 - S/W전자지갑을 다운로드 받아서 사용하는 방법
ex) ECash, NetCash, PayWord
- 컴퓨터의 높은 보급률과 통신망이 잘 발달한 미국에서 활성화
Ⅳ. 유통 형태
▶ 폐쇄형 - 이용자가 상점에서 이용 후, 즉시 발행기관으로 돌아가는 형태 / 대부분의 전자화폐
▶ 개방형 - 화폐가치가 이용자로 부터 다른 이용자로 유통되는 형태 / 대표적으로 Mondex
③ 전자화폐의 요구조건
▶ 실물화폐의 기능 - 운반가능성, 인식가능성, 양도성, 불추적성, 익명성, 교환성
▶ 추가적인 기능 - 독립성, 이중방지, 오프라인성, 분할성
④ 전자화폐의 안정성 및 요구 사항
▶ 안전성 : 물리적 안전성으로 위조의 어려움이 있어야하고 논리적으로도 안정해야함
▶ 프라이버시 : 사용자의 거래 내용은 상점은 물론 은행에서도 추적 될 수 없다. 익명성 보장되어야함
▶ 이중사용방지 : 부정한 사용자가 전자화폐를 불법적으로 복사 금지
▶ 오프라인 : 오프라인으로도 사용 가능해야함
▶ 부가적 요구조건(양도성) : 타인에게 양도 가능해야함
▶ 부가적 요구 조건(분할성) : 큰 단위 화폐는 작은 단위 화폐로 나눌 수 있어야함
▶ n회 사용가능 : 여러번 사용 가능해야함
⑤ 전자입찰 프로토콜
Ⅰ. 전자입찰 : 전자 상거래 방식을 통한 공개 구매시 다양한 거래선을 확보할 수 있고 구매 원가가 절감 된다
Ⅱ. 전자입찰 시스템의 구성요소
▶ 전자입찰 시스템 / 입찰공고자 / 입찰자로 구성
Ⅲ. 전자입찰의 문제점
▶ 네트워크상에 메시지 유출 - 입찰자와 입찰공고자의 정보가 유출될 수 있음 / 암호화하거나 도청에 대응
▶ 입찰자와 서버 사이의 공모 - 입차자들의 개인정보 유출
▶ 입찰자와 입찰공고자간의 공모 - 입찰자의 개인정보 보호 및 입찰 변조 및 누락 시킬 가능성
▶ 서버의 독단 - 서버가 특정 입찰자를 위해 나머지 입찰자의 정보를 누락하거나 변조할 가능성
Ⅳ. 전자입찰 시스템의 문제점 해결 방안
▶ 독립성 : 입찰자와 입찰공고자로 부터 독립해야 함
▶ 비밀성 : 네트워크 상의 각 구성 요소들의 정보는 누출되면 안됨
▶ 무결성 : 누락 및 변조여부를 막음
▶ 공평성 : 입찰이 수행될 때, 모든 정보가 공개되어야 함
▶ 안정성 : 각 구성 요소들의 공모와 서버의 독단 등이 일어나서는 안됨
Ⅴ. 전자입찰 프로토콜 방식
▶ LKR 방식
ⓐ S/MIME와 같이 안전한 전송로를 구축함 -> 제3자의 도청 및 변조를 방지
ⓑ 입찰 내용에 해쉬를 취하여 입찰자의 서명을 붙 임으로써 무결성 및 부인 방지를 가능하게 하는 방식
ⓒ 입찰 공고자의 서버가 하나로 구성 -> 입찰자의 입찰 정보를 제공함으로써 부정이 발생 할 수 있음
▶ PL방식
ⓐ 입찰 공고자와 서버가 공모할 경우 입찰예정가 및 입찰가 조작이 가능하다
ⓑ 입찰 공고자가 시방서 작성시 랜덤하게 선택함으로써 최적의 효율성을 확보하지 못하는 것에 문제점
⑥ 전자투표 프로토콜
Ⅰ. 요구사항
ⓐ 정확성 - 시스템이 투표용지를 수정, 삭제할 수 없다
ⓐ 비밀성
ⓐ 위조 불가능성
ⓐ 단일성 - 단지 한 번의 투표권만 행사
ⓐ 합법성 - 합법적인 절차를 통해 투표권을 얻은 사람만 투표에 참여 가능
ⓐ 공정성 - 투표 진행과정에서, 다른 사람의 투표권 행사에 영향 끼치면 안된다
ⓐ 확인성 - 투표자가 올바르게 투표했는지 확인가능해야함
ⓐ 투표권 매매방지 - 투표권을 타인에게 매매할 수 없음
ⓐ 완전성 - 투표자들이나 집계자의 부정으로 투표 시스템의 모든 투표 진행이 정지되거나 불완전한 결과 초래하면 안된다
Ⅱ. 전자투표 방식의 분류
▶ PSEV(Poll SIte E-Voting) - 국민 투표 활용
- 지정된 투표소에서 전자 투표를 하는 방식으로 유권자가 투표소 화면 인터페이스를 이용하여 수행
▶ 키오스크(Kiosk) 방식 - 무인 투표 시스템
- 군중이 밀집한 지역에 키오스크 투표기기가 설치해서 유권자가 투표 수행
- 공공망을 통해 집계되기에 악의적인 공격의 가능성이 크다
▶ REV(Remote E-Voting)
- 인터넷 투표를 하는 방식으로 다양한 기술 수단을 통해 원격으로 자유롭게 투표하는 방식
- 가장 이상적이지만, 비밀투표를 충족하기 어렵고, 투표권의 매매 위험이 존재함
Ⅲ. 전자투표의 암호화 기법
- 공개키/개인키를 이용한 암호화
- 전자서명
- 은닉서명 : 투표자와 투표결과 쌍을 이을 수 없도록 함
(3) 무선 플랫폼에서의 전자상거래 보안
① 무선플랫폼에서의 전자상거래 보안
▶ WPKI(Wireless Public Key Infrastructure)
-- WAP(Wireless Application Protocol)에서 서버와 클라이언트 간의 인증을 위해 사용되는 무선 환경에서의 공개키 기반 구조
-- 인증기관 / 등록기관 / Client 시스템 / PKI 디렉토리
- 신용카드기반 전자지불 시스템
-- 보안프로토콜 : End-To-End 간의 발생하는 트랜젝션의 안정성
-- S-HTTP/ SSL / TSL
-- 지불프로토콜 : 전자상거래의 모든 구성원들 간의 트랜젝션 정의를 위한 별도의 프로토콜
-- SET / InstaBuy(cyber Cash)
- 전자화폐기반 전자지불 시스템
-- 네트워크형 프로토콜 : 인터넷 같은 네트워크 환경에서 사용자의 PC나 서버의 계좌 등에 전자화폐를 저장하고 사용
--- Milicent(DEC) / NetBill(CMU) / Payword(MIT) 등
-- 가치저장형 프로토콜 : 스카트카드 내에 전자화폐를 저장해서 사용(실생활의 화폐 대용이 목적)
--- Mondex(master Card) / Visa Cash(Visa International) / Proton(Banksys) / K-cash(국내)
- 전자수표 기반 전자지불 시스템
-- 실제 수표와 유사한 형태로, 전자서명 같은 암호화를 통해 배서(어음이나 증권의 양도) 등의 효과를 제공
-- Echeck(FSTC) / NetCheque(USC) / Paynow(CyberCash)
(4) 전자상거래 응용보안
① e-biz를 위한 ebXML 보안
Ⅰ. ebXML(e-business using XML) : 비즈니스 데이터를 안전하게 교환하는데 XML을 사용한 개방형 표준
Ⅱ. ebXML 구성요소
Ⅲ. ebXML 보안
▶ XML에서 사용되는 보안이 대부분 ebXML에서 사용이 된다
▶ XML전자서명, XML 암호화, XKMS, SAML, XACML 등이 있다
[ 출처 ]
https://kit2013.tistory.com/211 [정윤상이다.] 의 글을 보완하고 수정한 글입니다.
'IT > 정보보안' 카테고리의 다른 글
네트워크 보안 - 포트 스캔 공격 (2) | 2019.07.02 |
---|---|
[정보보안기사] 애플리케이션 보안 - 보안 기술 (0) | 2019.06.28 |
[정보보안기사] 애플리케이션 보안 - 인터넷 응용 보안 (5) DB 보안 (0) | 2019.06.27 |
[정보보안기사] 애플리케이션 보안 - 인터넷 응용 보안 (4) 웹 보안 (0) | 2019.06.27 |
[정보보안기사] 애플리케이션 보안 - 인터넷 응용 보안 (3) DNS 보안 (0) | 2019.06.27 |
댓글