우리는 이제 전자서명에 대해 배울 것이다.
전자서명이 무엇과 비슷한 역할을 하는가?
MAC
Mac은 Sender와 Receiver사이에서 메시지의 integrety를 확인하는 방법으로 사용되며 Mac을 사용할 각 사용자와 key를 교환했어야 했다.
그렇기에 이는 소프트웨어 패치와 같은 방식에서 사용이 가능은 했으나 많은 사용자들과 Key를 공유하는 문제에 대해 해결이 필요했다.
또한 외부의 사용자가 메시지의 무결성과 분쟁에 끼어들기 힘들기에 Mac과 비슷한 역할을 하는 새로운 방식이 필요했다.
Digital Signature Scheme (DSS)
위의 문제를 해결하기 위해 나온 방식이 바로 전자서명 Cert이다.
전자서명은 만약 서버가 소프트웨어 패치 파일에 대해 전자서명을 생성하고 이에 대해 모든사용자에게 전자서명과 메시지를 주면 사용자는 이를 검증한하는 방식을 지닌다.
그렇기에 3가지의 알고리즘을 가지고 있다.
- KeyGen(i)
- Sign(SK, M)
- Verify(PK, S, M)
이러한 알고리즘과 아래의 구조를 가진다.
서명을 할 수 있는자는 Pk에 대응되는 Sk를 가진이만 서명을 생성할 수 있고 검증은 Pk로 검증이 가능하다.
따라서 Pk와 message, S모두 숨길 필요가 없기에 모두 검증이 가능하다.
제공해야하는 것
- sender authentication
- integrity
DSS는 Mac과 동일하게 위의 기능을 제공한다.
그리고 추가적으로 아래의 기능을 제공한다.
- public verifiability(공개 검증)
- transferability
- non-repudiation(부인방지)
그러나 DSS는 confidentiality를 제공하지 않는다.
Security of DSS
공격자에게 서명 검증키 Pk가 주어진다.
이후 공격자에게 CMA가 가능하다고 한다면?
공격자가 서명받기 원하는 메시지를 주면 이에 대한 서명을 제공하다 보면
공격자가 새로운 m',s'를 제공할 수 있으면 공격이 깨지는 것이다.
즉 Sk를 모르는체로 전자서명을 위조할 수 있는가?
그러나 이는 Existentially unforgeable하다.
긴메시지에 대해 서명은?
Hash-then-Sign Paradigm을 통해 생성한다.
메세지를 Hash를 돌려 나온 값에 대해 서명을 해준다.
그러나 이 Hash함수는 충돌저항성을 지녀야한다.
이에 대한 검증은 m에대해 H(m)을 구하고 이에대해 서명검증을 하면된다.
만약 충돌저항성이 없다면 충돌쌍을 찾아 검증시에 이를 바꿔치기한다면 서명 검증이 통과되어 공격자에게 유리한 것으로 변경이 가능하다.
Signature's
- Textbook RSA Signature
PK = (n, e) and SK = (d)
이방법은 메시지에 대해 d승을 하여 mod n을 한 값을 서명이라고 하고 받은이는 이 서명에 e승을 하면 message가 나오는지 확인한다.
그러나 이방법에는 한가지 문제가 있다.- No-message attack (select S, S의 e승 mod n)
- Known-message attack (given m1의 d승, m2의 d승 mod n à (m1m2)의 d승 mod n
이 공격들에 대해 취약점을 지니고 있다.
이를 극복하기 위해 아래의 방법이 사용된다.
- Hashed RSA Signature
이는 메시지가 들어오면 메시지에 대해 hash를 하고 이에 대해 d승을 하는 것이다.
검증 할 때는 동일하게 메시지에 대해 hash한 값과 들어온 값에 e승을 한 값이 같은지를 비교함으로 써 서명의 검증이 가능하다.
이는 앞에서 본 attack이 불가능하다.
- Known-message attack은 Hash의 일방향성을 깨야함으로 이를 깨기는 어렵다.
- No-message attack은 메시지에 Hash가 추가되었기에 Hash로 인해 값이 randomize되어 비교해도 다른 값이 나오기에 검증이 안된다.
이러한 방식을 사용하는 방법은?
In PKCS#1: H(M) = [00||01||FF||···||FF||h(m)]의 d승 (mod n) - Digital Signature Algorithm (DSA)
이러한 sub 그룹상에서 p를 잡아 서명을 한다.- Gen: PK = (H, p, q, g, y=[gx mod p]) and SK= (H, p, q, g, x)
- Sign: select a random k←Zq* and set r := [ [gk mod p] mod q] and s := [ (H(m)+xr)·k-1 mod q] signature = (r, s) ¡
- Vrfy: output 1 iff r =? [ [(gH(m)yr)1/s mod p] mod q ]
의 방식으로 서명을 생성하고 검증을 한다.
- ECDSA
- ECDSA-Setup(1n)
PK = (G, q, g, y=gx), sk = (x) - ECDSA-Sign(sk, m)
Pick random k ← Zp and set gk ∈G
r = F(gk) (mod q) and s =k-1(H(m) + xr) (mod q)
σ =(r, s) ∈ ZpⅹZp - ECDSA-Verify(σ, PK, m)
Compute w= s-1 (mod q)
A = (gH(m)yr)1/s and output 1 iff r = F(A) (mod q)
과 같은 방식으로 서명을 하고 검증을 한다.
- ECDSA-Setup(1n)
Digital Signature의 적용
이러한 곳에 전자서명을 적용할 수 있다.
Public Key Distribution
이전에 봤다 싶이 PK를 전달할 때 public망에서 그냥 전달한다면 이는 많은 공격자들이 바꾸기 공격을 할 가능성이 있다.
그렇기에 믿고 쓸 수 있는 방법이 필요하다.
trusted third party (called a Certificate Authority (CA))가 필요하다.
그러나 block-chain의 경우 이것이 필요없다.
CA의 경우는
CA generates its own keys (PKCA, SKCA)를 생성하고 이를 모든 구성원들에게 제공한다.
그리고 아래의 과정을 따라 진행된다.
위 사진에서 보다 싶이 Cert는 PKBob ||Bob||Sign(SKCA, PKBob||Bob )의 구성으로 되어있다.
이를 제공받은 서명검증이 성공한다면 제 3의 신뢰기관인 CA가 PK를 위변조가 없음을 제공한다.
X.509
Cert들에 만약 규칙이 없다면 무수히 많은 서명들에 대해 검증할 수 있는 알고리즘을 각각 깔아야하므로 Cert의 규격을 규칙화 해놓은 것이다.
위의 사진에서 보다싶이 많은 정보들을 가지고 묶어 서명을 해 전자서명을 만든다.
Certificate Revocation List (CRL)
CRL은 인증서들이 폐기 되었는지에 대해 정보들을 알 수 있는 list이다.
만약 Cert가 폐기되었는지 의심될 때는 검증자가 CRL에서 해당 Cert가 폐기되었는지 확인이 가능하고 만약 폐기된 인증서를 쓴다면 이 Cert를 쓴 응답에 거절을 하면된다.
Public Key Infrastructure (PKI)
CA밑에서 모든사람이 인증서를 발급받는다면 CA에 과부하가 올 것이다.
따라서 CA는 계층 구조를 지니고 있다.
위의 사진과 같이 3단구조를 통해 인증서를 제공하고 있다.
이러한 방식을 취하고 있기에 인증서는 3단 Chain을 지닌다.
CertCA1(PKu1), CertCA(PKCA1), CertCA(PKCA)
의 구조를 지니고 있다.
마지막의 RootCA는 selfSigned Cart를 제공한다.
왜냐하면 검증 할 수 있는 수단이 없기 믿고 쓰는 CA이므로 그냥 자신이 서명을 한다.
한국의 상황
How SK is stored (Korean Version)
인증서를 사용할 때마다 이 화면이 보이는 이유는 다음과 같다.
NPKI라는 폴더안에 SK가 그냥 보관하는 것이 아닌 CBC모드를 통해 암호화 되어있다.
CBC모드로 암호화 되어있기에 대칭키가 필요하므로 이는 PBKDF를 통해 생성하고 이 값을 통해 K를 만들고 이를 통해 Sk를 복호화해서 이를 가지고 서명을 하는 방식으로 진행된다.
DSS의 활용
- File Transfer
파일을 전송할 때 사용한다.
M을 그대로 전송하면 공격자에 의해 공격을 받게 되므로 Cert를 통해 이를 전달한다면 이 서명이 제대로 검증이 된다면 Sender 인증, Message 위변조를 확인할 수 있다.
이는 대칭키 기반의 MAC이 했던 역할을 완벽하게 대체할 수 있다. - Integrity Check using DSS
이 역시 소프트웨어 패치나 다운로드에서 사용될 수 있다.
위으 구조와 같이 CA를 통해 SW배포자가 Sw에 대한 Cert를 발급받아 사용자에게 전달하면 사용자는 이 3가지를 항복에 대해 받아 이를 검증하고 맞다면 SW를 설치를 아니라면 SW에 위변조가 있다는 것이르모 설치하지않으면 된다.
- Authentication using DSS
전자서명을 통해 자신을 인증하는 방법.
CA가 믿을 만하다면 Cert가 자신의 신분증으로 사용될 수 있다.
위의 그림과 같이 alice가 bob에게 3가지 요소를 전달하면 bob은 이를 믿을 수 없기에 alice임을 확약을 받아야하기에 한가지 Challege를 제공하고 이를 alice가 이 challge를 서명을 생성해 제공하고 bob이 이를 확인해
옳은결과가 나오면 alice임을 확약받을 수 있다.
Challge를 주는 이유: Challge가 없다면 돌아다니는 Cert를 복제해 그 사람인척 할 수 있기에 Challge-Response를 통해 사용자를 검증한다.
위의 그림은 앞에 그림과 달리 한방향 인증이 아닌 양방향인증을 할 때 사용하는 방법으로 위의 그림과 별로 다르지 않다.
상호인증하는 것이므로 2번의 Challge-Response가 사용된다.
은행서버와 사용자 사이에 인증서로그인을 할 경우의 위의 사진과 같이 동작을 한다.
전자서명과 Key-Exchange
- Diffie-Hellman Key Exchange
앞에서 본 봐야 같이 p,q를 통해 키를 교환하는 방식이다.
이러한 방식에 대한 동작은 passive한 공격자를 방어할 수 있지만
Active한 공격자에게는 이는 먹이감이 된다.- Man-In-the-Middle (MIM) Attack
active한 공격자 eve가 중간에 통신을 가로채서 alice에게는 bob처럼 bob에게는 alice인척하며 통신을 방해하지 않고 둘 사이의 모든 통신을 감청 할 수 있다.
이것이 가능한 이유는 eve가 중간에 멈춰 원본데이터와 다른 데이터를 전송하고 이를 알아차릴 수 없기에 이러한 문제가 발생하는 것이다.
하지만이는 Cert가 있다면 이러한 문제는 바로 해결이 가능하다.
왜냐하면 전자서명은 Sender인증, 메시지 인증을 제공하기 때문이다.
위의 그림에서 옆의 사진은 안전한 key교환만 하는 것이지 상호인증을 하지 않는다. - Station-to-Station (STS) protocol
Diffie-Hellman key-exchange를 하지만 조금 다르게 진행한다.
1,2,3번까지 동일한 작업은 하지만 bob은 3번에서 key를 구할 수 있기에 bob은 R1을 Challge로 R2를 Response로 해서 이를 서명하고 이를 key로 암호화해 alice에게 전송하면 alice는 R2가 오면 이를 통해 key를 구하고 이를 통해 아래의 Cert를 복호화해서 이를 서명을 검증한다.
이러한 식으로 한다면 상호인증과 key교환을 진행할 수 있게 된다.
특징: 대칭키를 통해 Cert를 암호화 한다.
이는 TLS 1.3에서 사용하고 있다. - Simplified STS protocol
이 방식은 위의 방식과 동일하나 한가지가 다르다.
그것은 바로 bob이 제공하는 Cert를 상호교환하는 key를 통해 암호화 하지않는다는 점이다.
이 프로토콜 역시 인증과 key교환을 하고있다.
이것이 안전하지 않은 것은 아니다.
이는 TLS 1.2에서 사용하고 있다.
안전성은 TLS 1.3이 더 안전하다.
- Man-In-the-Middle (MIM) Attack
- Authorization – ID card
이는 앞에서와 동일하지만 추가적으로 접근권한을 추가한 것으로 이를 통해 사용자의 부서 접근권한을 제한할 수 있다.
위와 동일하게 Random-Challge를 부여하고 이를 풀어준다음 해당 접근 구역에 맞는 사용자가 권한을 가지고 있다면 open아니면 거절하는 방식으로 Cert를 사용할 수 있다.
현실에서는 Card를 통해 거래핧 때 사용한다.
