2. 디지털 서명 및 검증 과정에 대한 정리
2020년 새해가 밝았습니다. 저는 다시 새마음으로 공부한 내용을 열심히 정리하고 성실히 게시활동 하려 합니다. 모두 새해 복 많이 받으세요~~ :)
지난 시간에는 Hash 함수를 통해 공개키, 비밀키 생성에 관한 내용을 살펴보았습니다. 가장 중요한 내용을 축약해보자면
- 해시함수는 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 함수이다
- 해시값으로부터 원본 데이터 값을 다시 추정하는 것은 불가능하다. (불가역성, 일방향 함수라고도 한다고 했습니다.)
- 입력값(원본 데이터)이 한 개라도 바뀌면 전혀 다른 해시값이 출력된다. (눈사태 효과)
- 출력값(해시값)은 입력값(원본 데이터)의 길이와 관계없이 항상 고정된 길이를 출력한다.
이를 토대로 공개키 암호에 대한 간단한 개념정리까지 했습니다. 이번에는 이 공개키 암호를 응용한 디지털 서명(전자 서명)과 검증 과정에 대해 명령어에 기반해서 정리해보려 합니다.
📌 1. 디지털 서명과 거래 자체를 구별하자
저는 UTXO(다음 시간에 정리할 예정입니다.)에 기반한 Locking Script와 Unlocking Script를 공부하면서 개념 자체가 어렵기도 하고 디지털 서명과 혼돈하면서 상당히 힘든 공부과정을 겪고 있습니다. 공부해보면서 내린 결론은 디지털 서명과 거래 자체를 구별해야 한다는 것입니다.
A라는 사람이 B라는 사람에게 비트코인을 송금하는 거래가 발생했다고 생각해 봅시다. 해당 거래를 'Sending'이라고 한다면 Sending 거래자체가 이루어지는 과정에서 UTXO를 이용한 Locking Script와 Unlocking Script 검증과정이 이루어지는 것이고 'Sending' 거래 자체를 다른 블록에도 전파를 해서 이 거래가 진짜라는 것으로 널리 알려야 하는데 이 때 디지털 서명과 서명 검증과정이 이루어진다고 생각하고 접근해야 합니다.
(저는 처음에 이상하게 이 부분이 헷갈려서 상당히 힘들었던 기억이 있네요..)
📌 2. 디지털서명 및 검증과정을 알기 전에 알아두어야 할 공개키 암호의 중요한 특징
검증과정을 정리하기전에 알아두어야할 공개키 암호의 중요한 특징이 있습니다. 간단하게 정리하고 넘어가려 합니다!
- 1. A의 공개키로 암호화 한 것은 A의 개인키로 복호화할 수 있습니다.
- 2. A의 개인키로 암호화 한 것은 A의 공개키로 복호화할 수 있습니다.
1번 케이스 같은 경우 누군가의 공개키로 데이터를 암호화 한다면 쌍을 이루는 해당 개인키로만 복호화할 수 있기 때문에 특정인에게만 데이터를 넘겨주고 싶을 때 1번 케이스를 이용합니다. 즉 데이터의 기밀성을 보장하면서 특정인에게 송신할 수 있습니다.
반대로 2번 케이스는 A의 공개키로 복호화할 수 있다는 점에서 데이터의 기밀성을 보장할 수 없습니다. 하지만 A의 개인키로 암호화한 것이기에 A가 메시지를 보냈다는 것은 조작할 수 없습니다. 즉 인증으로써 효력이 생긴다고 할 수 있습니다.
📌 3. 디지털 서명과 검증 과정
상당히 오래된 자료이긴 하지만 디지털 서명과 검증과정을 가장 쉽고 잘 설명하고 있어서 가져왔습니다. 메시지(데이터)자체를 개인키로 암호화하는 방법도 있고 위 그림처럼 메시지의 해시값을 개인키로 암호화하는 방법이 있습니다. 어찌됐든 메시지 송신자의 개인키로 서명을 완료하면 수신자에게 서명과 해당 메시지를 같이 보냅니다. 그러면 수신자는 받은 메시지에서 해시값을 도출하고 받은 서명을 송신자의 공개키로 복호화해서 얻은 해시값과 비교해 일치하는지 아닌지를 검증합니다. 만약 일치함을 확인하면 검증에 성공한 것이고 수신자는 해당 메시지를 다른 블록에 전파하게 됩니다. 이게 디지털 서명과 검증과정의 기본 절차입니다.
디지털서명은 서명 자체의 무결성을 증명하기 위한 것이 아닙니다. 즉 서명자체가 위조됐는지 아닌지를 검증하는 것이 목표가 아닙니다. 궁극적인 목표는 송신한 메시지 작성자가 진짜로 보낸 작성자인지 아닌지 판별해주고, 해당 메시지가 위변조되지 않았음을 증명해주고, 그리고 송신자가 해당 메시지의 작성 사실을 부인할 수 없도록 만드는데 있다고 할 수 있습니다.
📌 4. 직접 확인해보자!
Beanie가 Joy에게 1BTC 송금했다는 메시지를 송신하고자 할 때 송신자와 수신자 가운데 어떤 과정으로 검증이 이루어지는지 위의 그림을 토대로 알아보겠습니다.
🔖 4-1. 송신자인 Beanie가 보내려는 메시지에서 해시함수를 통해 해시값을 도출합니다.
sha256sum 명령어를 통해 message.txt의 해시값을 도출합니다. 이 명령어만 사용하면 뒤에 원본파일의 이름까지 기록되기에 64자리까지 cut한 후 hashed_message.txt에 저장합니다.
🔖 4-2. 송신자인 Beanie는 자신의 private key로 해시화된 메시지를 암호화합니다.
송신자는 해시화된 메시지에 개인키로 암호화를 함으로써 서명작업을 마무리 합니다. 여기서 사용되는 dgst 프로그램은 아래와 같이 설명되어 있습니다. (openssl dgst 설명 참고)
dgst 프로그램은 설명에 나와있듯이 디지털 서명을 생성(generate)하고 입증(verify)하는 기능을 가지고 있습니다. 이를 가지고 저번 시간에 만들어두었던 Beanie의 개인키를 이용해서 서명을 해보겠습니다.
sha256 해시함수를 사용해 beanie-private.pem(Beanie의 개인키가 담겨져있는 파일)로 암호화를 했습니다. 이제 서명도 완료했겠다 수신자인 Joy에게 토스할 차례입니다.
🔖 4-3. Beanie는 수신자 Joy에게 메시지와 서명을 보냅니다.
서명을 완료했으니 Joy에게 전달해주면 됩니다. 수신자인 Joy는 원본 메시지(message.txt), 서명(hashed_message.sig) 두 개의 파일을 받게 됩니다.
🔖 4-4. 수신자 Joy는 받은 원본 메시지를 해시화한 후에 서명을 Beanie의 공개키로 복호화해서 비교합니다.
위에서 서명에 사용됐던 dgst 프로그램은 디지털 서명의 생성 뿐만 아니라 검증기능까지 탑재하고 있습니다. 이를 이용해 Beanie가 보내준 메시지가 진짜로 Beanie가 작성해서 보낸 메시지인지 검증해보겠습니다.
위에서 언급했던 공개키 암호의 중요한 특징 중에 하나가 A의 개인키로 암호화된 데이터는 A의 공개키로 복호화할 수 있다는 특징입니다. Beanie의 개인키로 암호화(서명)를 했기 때문에 Beanie의 공개키로 복호화해야 합니다. 공개키는 누구에게나 공개되어있기 때문에 수신자인 Joy도 접근할 수 있습니다. Verified OK가 출력된 것으로 봐서 Beanie가 보내준 메시지가 진짜 Beanie가 작성하고 서명한 데이터임이 검증되었음을 알 수 있습니다.
📌 5. 나쁜 의도로 메시지를 전파하려는 사람이 있을 때는?
나쁜 의도를 가진 어떤 badguy가 Beanie가 10BTC를 본인한테 보냈다는 메시지를 전파하려고 할 때 어떻게 될까요? badguy는 위와 같이 조작된 메시지를 똑같은 과정을 거쳐 해시값을 도출하기까지 완료합니다.
해시화된 메시지를 본인의 개인키로 암호화해 서명하고 이를 수신자인 Joy에게 보냅니다.
수신자인 Joy는 Beanie가 보냈다고 생각해 Beanie의 공개키로 서명된 데이터를 복호화할 것입니다. 그리고 복호화된 메시지와 받은 원본데이터의 해시값과 비교합니다. 당연히 Verification Failure(검증 실패)라고 나옵니다. 개인키로 암호화(서명)한 데이터는 해당 개인키의 주인이 가지고 있는 공개키로 복호화할 수 있음을 꼭 명심하세요!~
이번 시간에는 디지털 서명과 검증과정에 대해서 정리해보았습니다. 다음 시간에는 송금대상이 되는 어드레스와 생성과정에서 사용되는 Base58Check 인코딩에 대해서 알아보도록 하겠습니다. 책과 구글링을 통해 지식을 접하는 만큼 어려운 개념을 이해하고 정리하는데 상당한 한계를 느낍니다. 블록체인 쪽으로 해박하신 분들의 지적과 코멘트는 저에게 너무나 큰 자산이 될 것 같습니다! 언제든 환영해요!~
틀린내용이 있을 수 있습니다 ㅠ 언제나 피드백 환영입니다!!~~
📌 6. 참고
- 디지털 서명, 헤시넷(hash.kr)
- 2010-1학기 현대암호학 「제 9장 디지털 서명」, 박종혁 교수님
- 「엔지니어를 위한 블록체인 프로그래밍」 다고모리 데루히로, 한빛미디어
'Blockchain' 카테고리의 다른 글
| 1. Hash 함수(Hash Function)와 공개키 암호 (0) | 2019.12.15 |
|---|