SET 프로토콜의 이중서명 쉽게 이해하기

보안을 공부하다 보면 배우게 되는 SET의 이중서명 방식. 교재에 나오는 짧은 설명만으론 이해가 쉽지 않다. SET 이라는 걸 실무에서 딱히 들어본 적도 없어, "그냥 옛날에 쓰이던 방식 같으니 공부 안해도 되겠지"라며 넘어가기도 한다.

 

그러나 이중서명 방식은 감히 말하던데, 필요최소한의 공개키·대칭키 암호를 가장 적절하게 잘 활용하는 전자상거래 암호학의 정수라고 말할 수 있다. SET이 사설 기업에서 만든 유료 프토토콜이라 "나 SET 이중서명 쓰고 있어요"라고 말하지 않아서 그렇지 실제로 이중서명 유사 방식은 전자 상거래에서 많이 사용된다. 

당신이 보안 프로토콜을 설계하든, 취약점을 분석하든, 기술사 공부를 하든 이중서명을 제대로 이해하면 활용할 곳이 정말 많다고 자신할 수 있다.

 

이 프로토콜은 필요최소한의 절차로 아래와 같은 보안의 주요 요소를 모두 실현한다.

1. 개인정보 보호
2. 기밀성 보장
3. 무결성 보장
4. 부인방지

자, 그럼 정말 이중서명을 이해하기 위한, 최대한 쉽게 풀어쓰는 설명을 시작하도록 하겠다. 풀어쓰다보니 다소 글이 길고 장황해질 수도 있으나 차례대로 읽어 나가면 누구든 다 이해할 수 있다.

 

1. 기본 패러다임

 

일단 이 프로토콜에선 고객과 상점과, PG사가 있다. 고객은 상점에서 물건을 사고 PG사를 통해 상점에 돈을 지불한다. 그런데 여기서 개인정보 이슈가 발생한다.

1. 고객은 상점에게 어떻게든 돈을 지불하기만 하면 된다. 굳이 상점에 내 카드 번호, 카드 비밀번호까지 공개해야 할까? 상점이 내 카드 정보를 악용할지 어찌 알고?
2. PG사는 그냥 상점으로 돈을 전달시키기만 하면 된다. PG사가 굳이 내가 어떤 쇼핑을 하는지 훤히 들여다봐야 하는가? 내 구매이력이 PG사에 쌓여나가는 것도 찝찝하다.
3. 즉, 고객은 상점에겐 구매 의사 표시를 하고, PG사에겐 돈만 전달하고 싶다. 상점은 고객의 정당한 요청에 정당한 대가만 받고 물건을 전달하고 싶다. PG사는 아무것도 모르고 돈만 전달하고 싶다.

단, 이것이 고객의 정당한 구매 요청인지, 결제 요청인지 등은 검증이 되어야 한다!

 

 

2. 검증 정보 준비

 

프로토콜에선 고객, 상점, PG사 모두 만족할 수 있는 검증 정보를 만든다.

 

1. 구매 정보
2. 암호화된 결제 정보
3. 검증 정보
4. 전자 서명
5. 암호 키를 담은 전자봉투

왜 이런 정보가 필요한지는 검증 과정에서 설명하도록 한다. 우선은 저 정보가 정확히 뭘 의미하는지 풀어봐야 한다.

 

1. 암호화된 구매 정보 = 상점의 공개키로 암호화된 구매 정보
2. 암호화된 결제 정보 = 대칭키로 암호화된 결제 정보
3. 검증 해시값 = hash(구매 정보), hash(결제 정보) 
4. 전자 서명 = "3. 검증 해시값"을 고객의 개인키로 암호화한 정보
5. 대칭키를 담은 전자봉투 = "2. 암호화된 결제 정보"를 암호화한 대칭키를 PG사의 공개키로 암호화한 정보

 

3. 상점의 검증

 

상점은 위에서 준비한 검증 정보를 다 전달 받는다. 상점이 봐야 하는 구매 정보는 상점의 개인키로 해제해 볼 수 있다.  상점이 볼 필요가 없는 결제 정보는 대칭키로 암호화되어 있고, 그 대칭키가 PG사의 공개키로 암호화되어 있어서 상점은 볼 수 없다.

 

상점은 이 정보가 고객의 정당한 요청아 맞는지, 중간에 제3자에게 조작되지 않았는지 확인해야 한다. 그러기 위해 저 검증 정보들이 사용된다.

 

1. 상점은 자신의 개인키로 암호화된 구매 정보를 복호화한다. 
2. 상점은 구매 정보에 hash를 적용한다.
3. 그 값이 "검증 해시값" 중에서 "hash(구매 정보)" 부분과 일치하는지 확인한다.
4. 고객의 공개키로 "전자 서명"을 풀어본다.
5. 전자서명을 풀어서 나온 값이 "검증 해시값"과 같은지 확인한다.

 

상점은 (1)~(2)의 과정을 통해 구매 정보가 조작되지 않았음을 확인할 수 있다. (무결성 검증)

상점은 (3)~(4)의 과정을 통해 이 구매 정보가 고객이 요청한 정보가 맞으며, 자신이 보지 못하는 결제 정보 또한 조작되지 않았음을 알 수 있다. (부인 방지, 무결성 검증)

 

 

4. PG사의 검증

 

PG사는 상점으로부터 검증 정보 중 구매 정보를 제외한 나머지 정보를 전달 받는다.

PG사는 구매 정보가 필요가 없다. 그저 이 결제 요청이 올바른 고객의 구매한 정보에 맞는 정당한 결제 요청인지만 알면 된다.

 

1. PG사는 "전자봉투"를 자신의 개인키로 복호화한다.
2. 복호화하면 대칭키가 나온다. 이 대칭키로 암호화된 결제 정보를 복호화한다.
3. PG사는 결제 정보에 hash를 적용한다.
4. 그 값이 "검증 해시값"에서 "hash(결제 정보)" 부분과 일치하는지 확인한다.
5. 고객의 공개키로 "전자 서명"을 풀어본다.
6. 전자서명을 풀어서 나온 값이 "검증 해시값"와 같은지 확인한다.

애초에 상점의 공개키로 암호화를 했으므로 상점은 (1)~(2)의 과정과 같이 대칭키를 취하고 암호화된 결제 정보를 확인할 수 있다. 그리고 나머지는 상점이 했던 것과 같이 (3)~(4)의 과정으로 무결성을 검증하고, (5)~(6)의 과정으로 정당성을 보장 받을 수 있다.

 

 

5. 결론

 

위 절차를 통해 각자 알아야될 정보만 확인하고, 모두가 정당한 정보임을 상호 검증하고 거래를 완료할 수 있다.

"왜 이렇게 복잡해야 하나?" 라고 생각할 수 있지만 따져보면 이 모두가 필요 최소한의 과정임을 알 수 있다. 과하지 않으면서 안전하게 기밀성 보장, 무결성 보장, 부인방지 효과를 누릴 수 있는 담백한 프토코콜인 것이다.

 

궁금한 점이 있다면 댓글을 달아주세요! 최대한 설명 드리도록 하겠습니다.

 

 

FAQ1. 결제 정보는 왜 애초에 PG사의 공개키로 결제 정보를 암호화하지 않았을까? 굳이 대칭키로 암호화하고, 그 대칭키를 공개키로 암호화할 필요가 있었을까?

 

이렇게 한 이유는, 단순히 PG사의 공개키로 암호화했을 경우 조작의 가능성이 있기 때문이다. PG사의 공개키는 누구에게나 공개되어 있는 공개키이다. 상점이, 또는 중간에서 정보를 가로챈 누군가가 조작된 결제 정보를 만들어 PG사의 공개키로 암호화해서 보내 버릴 수도 있다. 하지만 이렇게 공개키로 대칭키를 암호화하고, 대칭키로 결제 정보를 암호화하면 대칭키를 알 수는 없기 때문에 그런 조작이 불가능해진다.

어차피 그렇게 조작해도 검증 정보와 전자서명으로 대조해보면 조작 된 거 알 수 있지 않나? 라고 생각했다면 아주 바람직하다. 맞는 말이지만, 보안에서는 기본적으로 모든 참여자를 신뢰하지 않는다.

 

예를 들어, 만약 고객이 100만원치 물건을 사고 10만원으로 조작하려 한다면? 

3. 상점의 검증 -> 4. PG사의 검증 단계에서 정보를 가로채서 결제 정보를 조작할 수 있다. hash는 키가 필요 없는 암호화고, 전자 서명은 어차피 고객의 개인키로 하는 것이니 얼마든지 조작된 전체 정보를 만들어 낼 수 있다. 이런 경우까지 원천적으로 차단을 하는 것이다.