이중 서명

IT위키
175.119.151.228 (토론)님의 2019년 12월 1일 (일) 23:44 판 (→‎PG 검증)
Dual Signature
SET에서 고객의 프라이버시 보호 및 거래의 정당성 인증을 위해 고안된 전자서명 프로토콜

SET에서는 고객의 결제정보가 판매자를 통하여 해당 지급정보중계기관(PG)으로 전송됨에따라 고객의 결제정보가 판매자에게 노출될 가능성과 판매자에 의한 결제 정보의 위·변조의 가능성이 있으므로, 판매자에게 결제정보를 노출시키지 않으면서도 판매자가 해당 고객의 정당성 및 구매내용의 정당성을 확인 할 수 있고 PG는 판매자가 전송한 결제요청이 실제고객이 의뢰한 전문인지를 확인할 수 있도록 하는 이중서명 기술 도입이 필요하게 됨

절차

검증 정보 생성

  1. 고객의 전자서명 생성
    1. 구매정보에 Hash함수를 적용하여 B을 생성
    2. 결제정보에 Hash함수를 적용하여 P를 생성
    3. 생성된 B와 P를 연접(Concatenation)한 BP에 Hash함수를 적용하여 M을 생성
    4. M을 고객의 개인키로 암호화 → 전자서명
  2. PG에게 전해질 전자봉투 생성
    1. 대칭키를 생성[1]하여 결제정보를 암호화 후
    2. 해당 대칭키PG의 공개키로 암호화 → 전자봉투[2]
  3. BP, 전자서명, 구매정보[3], 암호화된 결제정보, 전자봉투를 판매자에게 전송

판매자 검증

  1. 판매자는 구매정보에 고객과 동일 Hash함수를 적용하여 B`을 생성
  2. 판매자는 BPB`P로 대체 후, 동일 Hash함수를 적용하여 M`을 구함
  3. 판매자는 전자서명고객의 공개키로 복호화하여 M을 추출
  4. 판매자는 M과 M'를 비교하여 동일한 경우 정당한 구매요청으로 간주하여 처리
  5. 판매자는 BP, 전자서명, 암호화된 결제정보, 전자봉투를 PG로 전송

PG 검증

  1. PG의 전자봉투 및 결제정보 복호화
    1. PG의 개인키전자봉투를 복호화하여 대칭키 추출
    2. 대칭키로 암호화된 결제정보 복호화
  2. PG의 고객 이중서명 확인 및 결제정보 확인
    1. PG는 결제정보에 동일한 Hash함수를 적용하여 P`를 생성
    2. PG는 BPBP`로 대체한 후 동일한 Hash함수를 적용하여 M``을 구함
    3. PG는 전자서명고객의 공개키로 복호화하여 M을 추출
    4. PG는 M과 M``를 비교하여 동일한 경우 정당한 결제요청으로 간주하여 처리

같이 보기

  1. Random Generate
  2. 결제정보를 바로 PG의 공개키로 암호화하지 않는 이유는, 이 정보가 판매자를 거쳐 PG사에게 전달되는데 판매자도 PG의 공개키를 알 고 있으므로 이 정보를 다른 정보로 바꿔치기 할 수 있기 때문
  3. 암호화 되지 않음