[정보보안기사] 애플리케이션 보안 - 전자상거래 보안

전자상거래 보안

---

- 목차 -

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 [정윤상이다.] 의 글을 보완하고 수정한 글입니다.