• 검색 결과가 없습니다.

담당교수: 차 영욱

N/A
N/A
Protected

Academic year: 2022

Share "담당교수: 차 영욱"

Copied!
45
0
0

로드 중.... (전체 텍스트 보기)

전체 글

(1)

9. SSL/TLS, 인터넷뱅킹 및 전자결제 9. SSL/TLS, 인터넷뱅킹 및 전자결제

담당교수: 차 영욱

담당교수: 차 영욱

ywcha@andong.ac.kr

(2)

목 차

q SSL/TLS 보안 프로토콜

l 핸드쉐이크 프로토콜 l 암호사양 변경 프로토콜 l 경고 프로토콜

l 레코드 프로토콜

q 인터넷뱅킹

l 인터넷뱅킹의 개요 및 접속 절차 l 금융기관별 ActiveX 설치 현황

q 전자상거래 절차 및 결제

l 비자 안심클릭

l 안전결재(ISP)

(3)

SSL/TLS 보안 프로토콜

q 보안소켓 계층(SSL: Secure Socket Layer)

l

1993년 웹 서버와 브라우저 사이의 안전한 통신을 위하여 Netscape 사에서 개발 à 현재 많은 웹 브라우저에서 사용되어 사실상의 업계 표준

l

HTTP뿐만 아니라 메일 전송을 위한 SMTP나, 메일 수신을 위한 POP3(Post Office

l

HTTP뿐만 아니라 메일 전송을 위한 SMTP나, 메일 수신을 위한 POP3(Post Office

Protocol) 같은 프로토콜이 SSL/TLS 상에서 동작할 수 있음

q 트랜스포트 계층 보안(TLS: Transport Layer Security)

l

1996년 발표된 SSL 버전 3.0을 기반으로 1999년 IETF가 TLS1.0(SSL3.1) 규격인 RFC2246 발표

(4)

SSL/TLS를 사용하지 않은 HTTP 통신

q 인터넷 서점에 영심이가 책을 주문

l

SSL/TLS를 사용하지 않고 웹 브라우저에서 웹 서버로 신용카드 번호를 보냈을 경우에 네 트워크 상에 신용카드 번호가 노출

(5)

SSL/TLS를 사용하는 HTTP 통신

q 인터넷 서점에 영심이가 책을 주문

l

HTTP를 SSL/TLS 상에 올려서 요청과 응답 메시지를 암호화 à 신용카드 번호의 노출을 방지할 수 있음

(6)

SSL/TLS의 보안 서비스 및 구조

q 인터넷 서점을 통한 책의 주문 시에 SSL/TLS가 제공하는 보안 서비스

l

기밀성: 주문자와 인터넷 서점이 교환하는 정보(예, 신용카드 번호와 주소)의 암호화

l

무결성: 공격자에 의하여 주문자와 인터넷 서점이 교환하는 정보의 위조나 변조 방지

l

인증: 주문자와 인터넷 서점의 상호 확인

l

인증: 주문자와 인터넷 서점의 상호 확인

q SSL 프로토콜의 구조

l

핸드쉐이크(Handshake) 프로토콜

l

암호사양변경(Change Cipher Spec) 프로토콜

l

경고(Alert) 프로토콜

l

레코드(Record) 프로토콜

핸드쉐이크

핸드쉐이크 암호사양변경암호사양변경 경고경고 핸드쉐이크

프로토콜 핸드쉐이크

프로토콜

암호사양변경 프로토콜 암호사양변경

프로토콜

경고 프로토콜

경고 프로토콜

레코드 프로토콜

레코드 프로토콜

(7)

핸드쉐이크와 암호사양 변경 프로토콜

q 단계 1~단계 3: 핸드쉐이크 프로토콜

l

클라이언트와 서버가 통신에 사용할 암호 및 인증 알고리즘과 공유 키를 결정하기 위한 암 호 스위트(cipher suite) 교환

l

인증서를 이용하여 상호 인증

l

인증서를 이용하여 상호 인증

q 단계 4: 암호사양변경 프로토콜의 메시지를 교환하므로 이전 단계에서 협의된 암호 스 위트의 적용을 개시한다.

보안 능력의 설정

단계 1

서버 인증 및 키 교환 클라이언트 인증 및 키 교환

암호사양 변경 메시지 교환 및 핸드쉐이크 종료

단계 2

단계 3

단계 4

(8)

핸드쉐이크와 암호사양 변경 프로토콜 절차

q

단계 1(보안능력의 설정): 메시지 1,2

q

단계 2(서버 인증 및 키 교환): 메시지 3,4,5,6

q

단계 3(클라이언트 인증 및 키 교환): 메시지 7,8,9

q

단계 4(암호사양 변경 메시지 교환 및 핸드쉐이크 종료): 메시지 10,11,12,13

q

단계 4(암호사양 변경 메시지 교환 및 핸드쉐이크 종료): 메시지 10,11,12,13

클라이언트 서버 클라이언트 서버

(9)

단계 1: 보안 능력의 설정

q (1)ClientHello(클라이언트→서버) q (2)ServerHello(클라이언트←서버)

l

사용할 수 있는 버전 번호, 현재 시각, 랜덤 값, 세션 ID

l

사용할 수 있는 암호 스위트(cipher suite) 목록

Ø

키 교환 방법:

ü RSA: 사전마스터 비밀 값(premaster secret)이 수신자의 공개키로 암호화되어 전달 ü Fixed Diffie-Hellman: 인증된 공개키 파라미터 값 교환

ü Anonymous Diffie-Hellman: 인증 없이 공개키 파라미터 값 교환

Ø

암호 명세(ChiperSpec): 암호 알고리즘(DES, 3DES, AES), 해쉬 알고리즘(SHA, MD5)

l

사용할 수 있는 압축 방법

(10)

단계 2: 서버 인증 및 키 교환

q

(3)Certificate(클라이언트←서버): 클라이언트가 수행하는 서

버의 인증을 위하여 서버의 X.509 인증서를 전달

l

단계 1에서 설정된 키 교환 방법이 Fixed Diffie-

Hellman인 경우 à 인증기관에 의하여 서명된 인증서로 Hellman인 경우 à 인증기관에 의하여 서명된 인증서로 공개키 파라미터 값 교환

q

(4)ServerKeyExchange(클라이언트←서버)

l

단계 1에서 설정된 암호 스위트의 키 교환 방식에 따라 서 다음과 같은 키 값 교환

Ø

RSA: 암호화한 사전마스터 비밀 값

Ø

Anonymous Diffie-Hellman: 공개키 값

q

(5)CertificateRequest(클라이언트←서버):

클라이언트를 인 q

(5)CertificateRequest(클라이언트←서버):

클라이언트를 인

증하기 위하여 클라이언트에게 인증서를 요청

q

(6)ServerHelloDone(클라이언트←서버): ServerHello 메시

지부터 시작해서 지금까지 교환된 메시지의 끝을 나타낸다.

(11)

단계 3: 클라이언트 인증 및 키 교환

q (7)Certificate(클라이언트→서버)

l

서버로부터 (5)CertificateRequest 메시지가 왔을 경우에 클라이언트의 인증서를 전달하는 메시지

l

단계 1에서 설정된 키 교환 방법이 Fixed Diffie-

l

단계 1에서 설정된 키 교환 방법이 Fixed Diffie-

Hellman인 경우 à 인증서로 공개키 파라미터 값 교환

q (8)ClientKeyExchange(클라이언트→서버)

l

단계 1에서 설정된 암호 스위트의 키 교환 방식에 따라서 다음과 같은 키 값 교환

Ø

RSA: 서버 인증서에 있는 공개키로 암호화한 사전마스 터 비밀 값

Ø

Anonymous Diffie-Hellman: 공개키 값

Ø

Anonymous Diffie-Hellman: 공개키 값

q (9)CertificateVerify(클라이언트→서버)

l

마스터 비밀키 값과 핸드쉐이크 메시지들의 결합에 대한 해쉬 함수 값(전자 서명)을 서버에게 전달하므로 클라이언 트가 전달한 인증서를 보장하게 된다.

(12)

단계 4: 암호사양 변경 및 핸드쉐이크 종료

q (10)ChangeCipherSpec(클라이언트→서버)

l

암호사양변경 프로토콜의 메시지를 교환하므로 이전 단계에서 협의된 암호 스위트의 적용을 개 시한다.

시한다.

q (11)Finished(클라이언트→서버)

l

핸드쉐이크의 종료를 통보하는 메시지

q (12)ChangeCipherSpec(클라이언트←서버)

l

암호사양변경 프로토콜의 메시지를 교환하므로 이전 단계에서 협의된 암호 스위트의 적용을 개 시한다.

시한다.

q (13) Finished(클라이언트←서버)

l

핸드쉐이크의 종료를 통보하는 메시지

(13)

마스터 비밀 값

q RSA 또는 Diffie-Hellman 키 교환

핸드쉐이크(키 교환)

RSA 또는 Diffie-Hellman 키 교환 à 사전마스터 비밀 값(premaster secret) 생성 à SHA-1과 MD5 해쉬함수를 이용한 48바이트의 마스 터 비밀 값 (master secret)생성 q 마스터 비밀 값은 SSL/TLS 통신의

대칭암호 키와 CBC(Cipher Block Chaining) 모드에 이용하는 초기백

터 그리고 메시지 인증에 사용되는 SHA-1과 MD5 à 마스터 비밀 값

사전 마스터 비밀 값

터 그리고 메시지 인증에 사용되는 비밀키의 생성에 이용된다.

마스터 비밀 값

(14)

마스터 비밀 값과 키 블록 생성

master_secret = MD5(pre_master_secret|| SHA(‘A’||pre_master_secret ||

ClientHello.random || ServerHello.random)) ||

MD5(pre_master_secret|| SHA(‘BB’ || pre_master_secret ||

ClientHello.random || ServerHello.random)) ||

q SSL/TLS 통신의 대칭암호 키와 CBC 모드의 초기백터 그리고 메시지 인증의 비밀키에서 요구 되는 충분한 길이의 키 블록이 생성될 때까지 master secret을 해슁하게 된다.

Key_block = MD5(master_secret|| SHA(‘A’ || master_secret ||

ClientHello.random || ServerHello.random)) ||

MD5(pre_master_secret|| SHA(‘CCC’ || pre_master_secret ||

ClientHello.random || ServerHello.random))

Key_block = MD5(master_secret|| SHA(‘A’ || master_secret ||

ServerHello.random || ClientHello.random)) ||

MD5(master_secret|| SHA(‘BB’ || master_secret ||

ServerHello.random || ClientHello.random)) ||

MD5(master_secret|| SHA(‘CCC’ || master_secret ||

ServerHello.random || ClientHello.random)) || . . .

(15)

경고 프로토콜

q SSL/TLS 통신 중에 발생한 에러를 전달하는 프로토콜

l

기대하지 않은 메시지의 수신(unexpected_message)

l

잘못된 메시지 인증코드(bad_record_mac)

l

압축해제 실패(decompression_failure)

l

압축해제 실패(decompression_failure)

l

핸드쉐이크 실패(handshake_failure)

l

잘못된 파라미터의 사용(illegal_parameter)

l

인증서 없음(no_certificate)

l

잘못된 인중서(bad_certificate)

l

지원되지 않는 유형의 인증서(unsupported_certificate)

l

폐지된 인증서(certificate_revoked)

l

인증서의 유효기간 경과(certificate_expired)

l

알수 없는 유형의 인증서(certificate_unknown)

(16)

레코드 프로토콜

q 서버와 클라이언트가 핸드쉐이크 프로토 콜을 사용해서 결정한 알고리즘과 키 값을 이용하여 대칭 암호화/복호화와 메 시지 인증코드(MAC)를 생성한다.

상위계층(예, HTTP) 메시지

단편

시지 인증코드(MAC)를 생성한다.

q SSL 메시지

압축

압축된 단편 인증 키

압축된 단편 SSL 헤더(메시지 유형, 버전, 길이)

암호화

암호 키

암호화된 단편

SSL 페이로드

압축된 단편

(17)

SSL 보안의 한계

q SSL은 점대점(point-to-point) 범위로 데이터를 보호할 수 있지만 중간 웹 서버를 통해서 다시 전달(forwarding) 되는 데이터의 보호는 보장되지 않음

à 응용 계층에서의 암호화를 통한 종 단 범위의 암호화가 요구됨

q 전체 메시지를 암호화/복호화하는 오버헤드 문제

à XML(eXtensible Markup Language)의

q 전체 메시지를 암호화/복호화하는 오버헤드 문제

à XML(eXtensible Markup Language)의

보안을 이용하여 필요한 정보만을 암호화

클라이언트 응용

중간 웹 서버 (인터넷 서점)

최종 웹 서버 (은행결제 시스템) SSL에 의한 데이터의 보호 구간(점대점)

(책 제목 및 수량, 주소 및 은행정보 및 주민번호)

은행정보 및 주민번호의 보호는 보장되지 않음

응용 (인터넷 서점) (은행결제 시스템)

네트워크 네트워크

클라이언트에서 최종 웹 서버까지 데이터를 보호할 수 있는 종단(end-to-end) 범위의 데이터(은행정보, 주민번호) 보호 필요

(18)

응용 계층에서의 XML 암호화

q 책을 주문하기 위한 XML 메시지

q XML 암호를 사용해서 신용카드 번호에 해당하XML 암호를 사용해서 신용카드 번호에 해당하 는 엘레멘트 만을 암호화 한 XML 메시지

신용카드 번호 암호문

(19)

인터넷뱅킹의 개요

q 세계 최초의 인터넷뱅킹

l

1995년 10월: 시큐리티퍼스트 네트워크은행(SFNB)

q 한국 최초의 인터넷뱅킹

l

1997년: 미래산업㈜ – 인터넷뱅킹 시스템 개발

l

1997년: 미래산업㈜ – 인터넷뱅킹 시스템 개발

l

2000년부터 대부분의 은행들이 인터넷뱅킹 시스템 구축

(20)

인터넷뱅킹 가입 및 인증서 발급

(21)

공인 인증서(yessign) 발급(1)

j 신한은행( http://banking.shinhan.com) 접속 → 공인인증 선택

k 보안 모듈 설치

(22)

공인 인증서(yessign) 발급(2)

m 공인인증서 발급/재발급 클릭

l 공인인증센터로 이동

(23)

공인 인증서(yessign) 발급(3)

n 약관 동의 체크 à 확인 클릭

o 공인 인증서 발급을 위해 주민등록번호, 출금계좌번호, 계좌비밀번호 입력 à 확인 클릭

(24)

공인 인증서(yessign) 발급(4)

p 보안카드 및 이체 비밀번호 입력(신규 발급 시 수수료 필요 - 재발급 시 불필요)

à 확인 클릭

(25)

공인 인증서(yessign) 발급(5)

q 공인 인증서 발급/재발급 à 발급 클릭

r 저장 매체 선택 à 확인 클릭

인증서 암호 입력 à 확인 클릭

(26)

공인 인증서(yessign) 발급(6)

s 발급 완료: C:\Program Files\NPKI\yessign의 하위 폴더에 인증서 저장

(27)

인터넷뱅킹 접속(1)

j 개인뱅킹 클릭 k 인터넷뱅킹 로그인 클릭

(28)

인터넷뱅킹 접속(2)

l 공인 인증서 선택 및 인증서 암호 입력

(29)

인터넷뱅킹 접속(3)

m 인터넷뱅킹 초기화면

(30)

인터넷뱅킹 이용절차(1/2)

⑧ 금융거래

패스워드카드 확인(송금 시) 패스워드카드 확인(송금 시)

(31)

인터넷뱅킹 절차(2/2)

① 사용자는 은행의 홈 페이지에 접속하여 인터넷뱅킹 로그인을 선택

② 은행은 사용자에게 인증서 비밀번호의 입력과 인증서 및 전자서명을 요청

③ 사용자는 인증서 비밀번호를 입력함으로써 컴퓨터에 저장되어 있는 인증서와 개인키를 이용하여 생성한 전자 서명을 은행에 전달

④ 은행은 인증서가 유효한 인증서인지 인증기관에 문의

⑤ 인증기관은 인증서의 디렉터리 검색을 통해 사용자의 인증서 상태를 확인한 후, 사용 자 인증서의 신뢰 여부를 은행에 전달

⑥ 신뢰할 수 있는 인증서인 경우에 은행은 사용자의 공개키(인증서에 포함된)로 전자 서 명을 복호화하여 사용자가 보낸 것이 확실한지 검증

⑦ 위의 단계가 검증되면 은행은 사용자에게 금융 서비스의 접근을 허용

⑦ 위의 단계가 검증되면 은행은 사용자에게 금융 서비스의 접근을 허용

⑧ 사용자는 잔액 확인, 송금 등과 같은 인터넷뱅킹을 수행한다. 송금 서비스를 위하여서

는 패스워드 카드의 번호와 이체 비밀번호를 입력하여 한다.

(32)

금융기관별 ActiveX 설치 현황 목록

q 국민은행

l nProtect Security Center(nProtect Netizen V4.0): INCA

l XecureWeb Control V7.2(XecureWeb ClientSM 4.1.1.0): SoftForum

q 우리은행

l XecureWeb Control V7.2(XecureWeb ClientSM 4.1.1.0): SoftForum

l ClientKeeper KeyPro Keyboard Protecter:

SoftForum ClientSM 4.1.1.0): SoftForum

l INISAFEWeb v6: Initech l INIIE8Assist: Initech

l Secure KeyStroke 4.0 : Softcamp

q 신한은행

l INISAFEWeb 7.0 Updater: Initech l Secure KeyStroke 4.0: Softcamp

l Secure KeyStroke Elevation COMDLL:

Softcamp

SoftForum

l Ahnlan Online Security: AhnLab

l XecureWeb UCA Update Control: SoftForum l WRebw: Interzen

q 외환은행

l VeraPort: WIZVERA

l VeraPort Main: WIZVERA

l nProtect Security Center (nProtect Netizen V4.0): INCA

l ClientKeeper KeyPro Keyboard Protecter:

Softcamp

l ProWorksGrid: Iniswave

l Ahnlan Online Security: AhnLab

l ClientKeeper KeyPro Keyboard Protecter:

SoftForum

l XecureWeb Control V7.2(XecureWeb ClientSM 4.1.1.0): SoftForum

(33)

금융기관별 ActiveX 설치 현황 목록

q

잉카인터넷 사의 nProtect Netizen: 악성프로그램(해킹툴, 특정 바이러스 등)을 자동 진단 및 차

단하고, PC 보안을 위한 다양한 기능을 제공하여 개인정보 유출을 차단

q

소프트포럼 사의 XecureWeb Control V7.2: 암호화/복호화 및 사용자 인증을 바탕으로 웹,

DB, 메일 등 다양한 어플리케이션에 데이터 무결성, 기밀성 보장, 사용자 부인 방지 기능을 제공 DB, 메일 등 다양한 어플리케이션에 데이터 무결성, 기밀성 보장, 사용자 부인 방지 기능을 제공 하는 PKI 및 PKI 응용 프로그램

q

Initech 사의 INISAFEWeb 7.0: 128비트 암호화 기술을 이용하여 웹 브라우저와 웹 서버 사이

에 교환되는 데이터의 암호화, 디지털 인증서를 이용한 전자서명 지원

q

Softcamp 사의 Secure KeyStroke 4.0: 키보드를 통해 입력되는 사용자의 중요 정보를 키보

드 인터럽트 레벨에서 암호화 하여 악의적인 해킹이나 공격을 방지하는 솔루션

q

AhnLab의 Ahnlan Online Security: 온라인을 통해 처리되는 모든 정보의 교류가 안전한 상태

에서 이루어지도록 안티-키로거(anti-keylogger), 방화벽, 안티-바이러스/스파이웨어, 시큐어 브라 우저의 4가지 보안 서비스로 구성되어 있다

우저의 4가지 보안 서비스로 구성되어 있다

q

소프트포럼 사의 Keyboard Protector: 키보드를 통해 입력되는 사용자 중요 정보를 보호하기

위한 키 입력 해킹 방지 컴포넌트

q

WIZVERA 사의 VeraPort Main: 인터넷뱅킹 등의 서비스를 위한 보안 프로그램의 설치 과정을

단순화하도록 도와주며, 보안 프로그램으로 인한 장애 상황을 빠르게 대처할 수 있도록 도와주는 프로그램

(34)

결제대행업체

q 쇼핑몰은 상품의 등록 및 주문만을 담당하며, 상품 금액의 지불은 결제대행업체(PG:

Payment Gateway)가 담당

l

보안 서비스와 다양한 지불/정산 솔루션(신용카드, 실시간 이체, 핸드폰 결재 등)을 쇼핑몰 에 제공

에 제공

q PG 업체

l

LG U+: http://ecredit.dacom.net/, 이니시스: http://www.inicis.com/

l

티지코프: http://www.tgcorp.com/, KCP: http://www.kcp.co.kr/

(35)

에스크로 서비스

q 거래합의 후 상품배송 및 결제과정 중의 거래사고를 예방하기 위하여 에스크로 (escrow) 사업자(통상적으로 결제대행업체)가 거래대금의 입출금을 공정하게 관리 (2006.4.1 전자상거래 소비자보호법에 따른 의무 시행)

q 에스크로 의무시행 거래: 10만원 이상의 현금 거래(기존 무통장입금 거래 포함) q 에스크로 의무시행 거래: 10만원 이상의 현금 거래(기존 무통장입금 거래 포함) q 에스크로 면제 거래

l

신용카드로 구매하는 거래 및 10만원 미만의 현금 거래

l

배송이 필요하지 않은 재화 등을 구매하는 거래(콘텐트 등)

에스 크로

(36)

전자상거래 절차 및 결제

q 신용카드결제

l

비자 안심클릭

l

안전결제(ISP: Internet Security Payment)

l

일반 카드결제: 카드번호, 유효기간, 비밀번호(2자리), 주민등록 번호

l

일반 카드결제: 카드번호, 유효기간, 비밀번호(2자리), 주민등록 번호

(37)

비자 안심클릭

10만원 미만 결제 시

q 카드 번호와 함께 거래금액이 10만원 미만인 경우는 안심클 릭 패스워드(카드 인증)로, 10만원 이상인 경우는 안심클릭 패스워드 입력과 함께 공인인증서(본인 인증)를 제출

q 정보 전송 시 VISA 에서 개발한 3-D Secure 프로토콜 및 SSL사용

10만원 이상 결제 시

및 SSL사용

(38)

인터넷 안전결제(ISP)

q 안전한 전자상거래를 이용할 수 있도록 국민카드와 BC카드가 공동으로 개발한 전용 지불수단

BC카드가 공동으로 개발한 전용 지불수단

l

상품을 결제하기 위하여 인증서가 있는 컴퓨터에서 ISP 비밀번호(6~14자리)를 입력하여 결재함

l

입력된 ISP 비밀번호를 통한 전자서명을 통해 모든 거 래가 이뤄지므로, 신용카드 정보(카드번호, 유효기간)와 주민등록 번호의 입력이 필요없음

l

공개키(PKI)기반의 전자인증방식(공개키1024비트) 및 128비트의 SEED 암호화

l

10만원 미만의 거래인 경우는 ISP(카드 인증)로 결제, 10만원 이상의 거래인 경우는 ISP로 결제 후 공인인 증서(본인 인증)를 통해 한번 더 확인

증서(본인 인증)를 통해 한번 더 확인

(39)

인터넷 안전결제(ISP) 절차

①결재화면 실행

②10만원 이상일 경우 공인인증서 이용

③결제정보 및 전자서명을 암호화 하여 전송

회원 쇼핑몰

부가가치통신망 (VAN)

결제대행업체 (PG)

⑧지불결과

⑤카드사에 인증 및 승인요청

④승인 요청

(ISP+공인인증서) ⑦승인결과

전자서명 검증, 공인인증기관

국민/비씨카드사

전자서명 검증, 인증서 유효성 검사,

신용카드 번호추출

o승인결과(카드번호 앞 12자리포함-거래 내역 조회 시 필요)

(40)

ISP 발급 절차(1)

j ISP를 사용하는 카드(BC, 국민..)를 이용한 인터넷 결제하기

k ISP 플러그인 실행à ISP 신청 클릭

(41)

ISP 발급 절차(2)

l 카드 번호 및 E-Mail 주소 입력 à 다음 클릭

m 신용카드 정보 입력 à 다음 클릭

(42)

ISP 발급 절차(3)

n ISP 비밀번호 설정 à 다음 클릭

l

비밀번호 입력 만으로 인터넷 결제 가능

l

10만원 이상 결제 시 공인 인증서 필요

o 인증서 저장 위치 설정 à 확인 클릭

(43)

ISP 발급 절차(4)

p 발급 완료 à 확인 클릭

(44)

요점 정리(1/2)

q SSL(Secure Socket Layer)과 TLS(Transport Layer Security)

l

웹 서버와 브라우저 사이의 안전한 통신을 위하여 Netscape 사가 1993년 개발

l

SSL 버전 3.0을 기반으로 1999년 IETF가 TLS1.0(SSL3.1) 규격인 RFC2246 발표

q SSL 프로토콜의 구조

l

핸드쉐이크 프로토콜: 클라이언트와 서버가 통신에 사용할 암호 및 인증 알고리즘과 공유 키를 결정하기 위한 암호 스위트를 교환하며, 인증서를 이용하여 상호 인증을 수행

l

암호사양변경 프로토콜: 핸드쉐이크 프로토콜에 의하여 협의된 암호 스위트의 적용을 개시

l

경고 프로토콜: SSL 통신 중에 발생한 에러를 전달하는 프로토콜

l

레코드 프로토콜: 클라이언트와 서버가 핸드쉐이크 프로토콜을 사용해서 결정한 알고리즘과 키 값을 이용하여 대칭 암호화와 메시지 인증코드(MAC)를 생성

q SSL 보안의 문제점과 해결책

l

점대점 범위의 데이터 보호 제공 à

종단 범위의 보호를 위하여 응용계층의 암호화 요구

l

전체 메시지를 암호화 à

XML 보안을 이용하여 필요한 정보만을 암호화

(45)

요점 정리(2/2)

q 인터넷뱅킹 절차

① 인터넷뱅킹 로그인 à 사용자는 인증서 비밀번호를 입력 à 개인키를 이용하여 생성한 전 자 서명과 컴퓨터에 저장되어 있는 인증서를 은행에 전달

② 은행은 수신한 인증서가 유효한지 인증기관에 문의 à 유효한 경우에 사용자의 공개키(인증

② 은행은 수신한 인증서가 유효한지 인증기관에 문의 유효한 경우에 사용자의 공개키(인증 서에 포함된)로 전자 서명을 복호화하여 검증

③ 은행은 검증된 사용자에게 인터넷뱅킹 서비스의 접근을 허용

④ 송금 서비스를 위하여서는 패스워드 카드의 번호와 이체 비밀번호를 요구

q 전자상거래에서 쇼핑몰에게 보안 서비스와 다양한 지불/정산 솔루션을 제공하기 위하 여 상품 금액의 지불은 결제대행업체(PG: Payment Gateway)가 담당

q 거래합의 후 상품배송 및 결제과정 중의 거래사고를 예방하기 위하여 에스크로 사업 자(통상적으로 결제대행업체)가 거래대금의 입출금을 공정하게 관리

q 신용카드결제

참조

관련 문서

프로그래밍에서, 프로그램을 작성하기 위한 일련의 부(Sub) 프로그램, 프로토콜 등을 정의하여 상호 작용을 하기 위한 인터페이스 사양을 말한다... 자료 :

○ 장래교통수요예측을 위한 일련의 과정 수행 후 대안별로 도출한 장래수요예측 결과를 이용하여 일일 및 연간 운영수익금을

공격자가 도청공격을 할 경우 기존의 해쉬 락 인증 방법은 공격자를 태그나 리더 - 로 인식하여 공격자가 전송한 정보에 응답을 하기 때문에 리더와 태그 사이의

기존 인증 방식의 인증 절차에서 상호 인증을 수행하기 위해서는 수 차례의 핸드쉐 이크 과정을 거쳐야만 상호 인증이 가능하였다.이러한 과정에서 단말은 인증서의

컴퓨터의 허술한 부분을 이용해서 자료나 로그인 정보를 몰래 빼오거나 파괴하는 것을 말한다. 단순한 입력을 반복해서 원하는

시시때때로 바뀌는 코로 나 상황을 고려하여 모든 수업을 원격으로 진행하였고 학습자의 흥미를 높이기 위해 게이미피케 이션의 요소(포인트, 미션수행, 암호 등)를 일부

구매자는 NetBi l l서버의 지불 승인을 받은 후 상품을 수령하고,판매자는 결제 가 일어난 후 상품을 전달하기 때문에 구매자와 판매자 모두가 상호 신뢰할 수 있

제46조의4(행정정보시스템의 상호 연계 및 통합) ① 행정협업과제를 수행 하는 행정기관의 장은 행정협업과제의 원활한 추진을 위하여 행정기관 간