PART2. 보안과 암호 - SECTION 5. 전자서명과 공개키 기반 구조 (PKI)

1. 전자서명(디지털 서명)

무결성과 부인 방지가 제일 중요함.

전자서명과 같은 말임. 

가. 개요

원본의 해시값 = 무결성 확보

부인방지 기능을 위해 공개키 방법 사용

송신자는 메시지의 해시값을 구한 후 그 해시값을 송신자의 개인키로 암호화하여 보내는 것

 

송신자만이 가지고 있는 송신자의 개인키를 가지고 해시값을 암호화하는게 해시후 서명방식

송신자의 개인키로 암호화 -> 송신자의 공개키로 복호화 -> 부인방지 

전자 서명은 메세지를 암호화하지 않음 -> 기밀성 제공x  -> 물론 해도 됨. 근데 속도도 느리고 우유 2개 산게 뭔상관 

 

나. 개발 배경

부인방지+ 무결성 중요

기밀성은 들어가면 속도 느려짐

 

대용량은 대칭키 암호화 방식이 유리한데 비밀키 암호화해야해서 키 보안 어려움. 그래서 공개키 암호화 방식 만듦 근데 중간자공격에 취약함. 공개키를 관리하지 않고 공개하니까 그걸로 해커가 장난치네, 그래서 공인인증서 PKI가 나옴.

공개키 보호가 목적임. 이걸 응용한게 전자서명과 SET임

전자서명은 부인방지, 무결성 보장/ 기밀성은 보장하지 않음

SET은 민간 카드사에서 만들었는데, 개꿀이라 국제 표준이 됨. 기밀성, 무결성, 가용성, 부인방지, 인증 다 됨 굿

 

다. 전자서명 서비스

A의 공개키+개인키, B의 공개키+개인키 -> 공개키 레파지터리에 공개키 올리고, 

A의 거래내역을 해시함수로 돌려서 고정길이의 해시값 만들고 전자서명 생성정보

해시값은 짧은 메시지 다이제스트라고 부름. 그리고 이 짧은 메시지를 서명함 -> 해시후 서명 방식

전자서명은 거래내역을 묶어서 전자서명 검증정보를 만듦(기밀성 제공 ㄴ) -> 암호화 해도 됨; 근데 빵 세개 산게 뭔 상관이냐고 ㅜ

이걸 인터넷에 보냄. 이제 그걸 B가 받음. 해시값 복호화 함 송신자의 공개키로 복호화함. 부인방지, 서명 생성자 인증

받은 메시지를 같은 해시 함수로 돌림 A가 보낸 해시값과 같으면 무결성과 인증성 확인.

 

1) 메시지 인증: 메시지가 중간에 바뀌지 않았음 -> 무결성

2) 발신자 인증: 서명 생성자 확인

3) 부인방지: 송신자 개인키로 암호화 -> 송신자 공개키로 복호

 

라. 전자 서명의 주요기능

1) 위조불가

A가 빵 10개 샀는데, B가 받은 메시지의 해시도 같아야함

2) 서명자 인증

송신자가 자신의 개인키로 암호화해서 보낸 해시값을 송신자의 공개키로 복호화 함 -> 부인방지, 서명 생성자 인증

3) 부인방지 = 부인봉쇄

송신자가 자신의 개인키로 암호화해서 보낸 해시값을 송신자의 공개키로 복호화 함 -> 부인방지, 서명 생성자 인증

4) 변경불가

내용이 바뀌면 해시값이 바뀜

5) 재사용 불가

이중 결제 되잖아.. 재사용 되면, -> nones값이나 타임스탶프 등을 넣음.

 

마. 전자서명

 

1) 공개키를 사용하는 전자서명 방식(부가형 전자서명 방식)

가) 개념

해시값을 송신자의 개인키로 암호화 하는 행위 = 전자서명

전자서명은 기밀성을 보장하지 않음.

기밀성 보장하면 느려짐. 그래서 짧은 메시지 다이제스트를 암호화 하는 것임!

 

나) 메시지의 해시값에 서명하는 방법

메시지에 해시값을 만들어서 그 해시값을 송신자의 개인키로 암호화 해서 서명하는 방식

 

다) 전자서명 특징

메시지를 암호화하지 않음. 기밀성을 지키는게 목적이 아님.

금액이 안바뀌는게 중요함. 빵 세개 뭔 상관

 

라) 전자서명 구비조건(제공가능)

1) 무결성

2) 서명자 인증 기능제공: 제가 진짜예요...!... 누구든지 송신자의 공개키를 가져다가 인증 기능 -> 진짜임을 인증-> 서명자의 공개키

3) 부인방지: 송신자 개인키로 암호화 -> 송신자 공개키로 복호화

4) 재사용 불가

5) 위조 불가 

 

마) 공개키 방식을 이용한 전자서명의 문제점

중간자 공격에 취약하네 PKI를 만들자. 

 

메시지를 수신자의 공개키로 암호화 해도 됨. 근데 짧은 메시지 다이제스트를 하는 이유는 파일 암호화

 

대칭키 암호화 방식과 공개키 암호화 방식인데 공개키 암호화 방식이 중간자 공격에 취약해서 PKI를 만들었고, 전자서명과 SET이 됨.

메시지를 수신자의 공개키로 암호화하지 않고 짧은 메시지 다이제스트를 송신자의 개인키로 암호화하는 것임. 성능저하 극복을 위해 해시값을 암호화하는 것임. 

 

전자서명 하이브리드 방식

A와 B의 공개키와 개인키 공개키는 레파지터리에 올림

A의 메시지를 해시값을 만듦 -> 짧은 메시지 다이제스트 

이걸 전자서명함 -> 암호화된 전자 서명

메시지와 암호화된 전자서명을 묶음. ->  B의 공개키로 암호화함.  -> A의 서명 검증

- 메시지 암호화는 잘 안함 -> 너무 오래걸림. 빵 우유 산걸...왜...

아무튼 이걸 B에게 보냄. 받은 B는 전자서명을 A의 공개키로 복호화해서 해시값을 받음 -> 서명 생성자 인증, 부인방지

그리고 메시지를 해시함수를 돌려서 A가 보낸 해시값과 돌린 해시값이 맞는지 확인 함 -> 무결성, 인증 

 

2) 메시지 복원형 전자서명(메시지에 직접 서명하는 방식) 

가) 개념

내가 벤쳐 기업이면 전자 서명을 이용해서 수많은 서비스를 만들 수 있겠징. 실제로는 안쓴대...................................

해시함수를 쓰지 않는 특징이 있음. 해시 함수 안쓰고 A의 개인키로 암호화 하는 방식임.

 

바. 전자서명이 제공하는 보안서비스

1) 본인인증: 송신자의 신원확인 -> 무결성

송신자의 개인키로 암호화하고 송신자의 공개키로 복호화가 되면 인증과 무결성이 증명이 됨.

2) 무결성

3) 부인방지

4) 기밀성 없음! -> 해도 되는데, 빵 사고 우유 산거 알면 머할건데;;;

-> 빠른 동작과 무결성이 중요함 

 

 

사. 서명 방식의 종류

1) 은닉서명: 송신자의 익명성 보장->먹지가 하나 쓰면 뒤에 박히지 

2) 수신자 지정서명: 수신자를 정할 수 있는 서명

3) 부인방지 서명: 오리발 놉

4) 위임서명: 대신해줘

5) 다중서명: 책임을 분산시키기 위해 하나의 결정에 대해 여럿이 서명하는 것 -> 공동책임

6) 이중서명: SET -> PKI의 SET 

사기업에서 만든 표준, 상점이 카드 사용자의 계좌번호 등을 모르게 하는 채 상점이 요구한 결제 대금은 맞나 확인

 

아. 은닉서명에 대한 자세한 설명

1) 은닉서명

가) 은닉서명

나) 은닉서명의 목적

다) 은닉서명의 특징

  (2) 송신자의 익명성 보장

라) 은닉서명의 문제점

2) 은닉서명의 역기능 방지 기술과 특징 비교

가) 은닉서명의 역기능 방지를 위한 공정은닉서명

나) 은닉서명과 공정한 은닉서명의 특징 비교

3) 은닉서명의 응용분야

 

공개키 방식이 중간자 공격에 취약하네, 그래서 생긴게 PKI 이걸 응용한게 전자서명과 SET

전자 서명은 기밀성 보장 안하고(전자상거래), SET은 기밀성 보장 함. 

 

2. PKI(공개키 기반 구조)

가. 개념

인증서는 주로 x.509형식 사용, 인증서 발급 기관을 CA라 한다.

OCSP로 인증서의 폐기 여부를 확인함

변조를 막기 위해 인증기관(CA)의 서명이 추가된다.

 

83p에 PKI의 구조

공인인증기관 = 금융결제원

RA = 은행창고

다 인증서 하나씩 있음. 처음에 인증서 만들 때 보면 은행창구에 가서 인증서...하면 신분증 달라하고 신분을 확인함(기억은 안나겠지만) 이렇게 하는 이유는 나(A)가 공개키와 개인키를 공개키 레퍼리토리에 그냥 공개함 그랬더니 중간자 공격에 취약하네? 그래서 금융 결제원에서 X.509인증서에 A의 공개키를 담고, CA의 개인키로 A의 공개키를 암호화함. 그걸 B가 필요하면 가져감 가져가서 CA의 공개키로 A의 공개키를 복호화하고 사용함. B의 개인키로 암호화하는게 아니라 공인 인증기관(금융결제원)의 개인키로 암호화 함.

 

제 3의 신뢰된 기관

PKI는 공개키를 키 관리 센터와 같은 신뢰할 수 있는 제 3자를 통해 전달함.

 

나. PKI가 나온 이유

전자상거래를 하려면 공개키 암호화 써야하는데 중간자 공격에 취약해서 

 

공개키 암호화 방식은 A와 B의 공개키와 개인키, 공개키 레파지토리에 공개키를 올림.

그리고 A가 B의 공개키로 암호화해서 B에게 자룔를 넘기면, B가 개인키로 복호화 함

-> 근데 중간자 공격(MITM)에 약함.

A가 B의 공개키를 가져갈 때 해커가 자신의 공개키를 B로 속여서 A에게 줌. 그럼 A는 해커의 공개키로 암호화 함. 그걸 해커가 자신의 개인키로 복호화하고, 파일 편집 후(안해도 됨), B의 공개키로 암호화해서 B에게 넘김. B는 그걸 받음. 

 

중간자 공격은 중간에 끼어 드는 거

 

전자 상거래는 대칭키 방식으로 하려니 키관리 어려워서

공개키를 썼는데 MITM에 약해서 PKI가 생겼고, 그걸 응용한게 전자상거래와 SET임.

 

은행 계좌조회 공개키 사용 예

내가 휴대폰으로 은행 어플을 이용해서 내 계좌 잔액을 보려고 함. 나의 공개키/개인키가 있음. 내 계좌내역 ㅇㅇ.

자 그러면 이거를 평문으로 인터넷을 통해 주면 안되지. 그래서 은행이 나의 공개키를 은행에 줌. 그걸 은행이 내 공개키로 암호화해서 A의 개인키로 복호화함. 이게 PKI의 뼈대임

 

A와 B가 있음 B가 나한테 평문을 암호화 해서 주고 싶음. 공개키 암호화 방식을 쓴다면, 내 공개키와 개인키를 만들겠지. 그럼 B는 A의 공개키가 필요함. 사전에 인증서를 만들었음. (은행창구, 등록기관:RA) 은행 창구의 모니터는 공인인증기관(금융결제원,CA)과 연결되어있음. 은행에서 신분증 달라고 함. 확인이 됨. 금융 결제원의 공개키와 개인키를 만들어서 X.509인증서에 내 공개키를 금융결제원의 개인키로 내 공개키를 암호화 함. 암호화된 X.509인증서를 디렉터리 서비스에 올림. B는 X.509를 받ㄷ고, 금융 결제원의 공개키로 복호화해서, A의 공개키를 받아서, 평문을 암호화해서 A에게 보냄.

 

곰은 둥글다. 공인인증기관은 등글다~

공인인증기관 등록기관

 

공인인증서 다 가지고 있는데 전자상거래에서 불편해서 욕은 먹는데 공인인증서가 뚫린 적은 없음.

-> 해킹사례는 본인 비번 제대로 관리 안한거임..ㅎㅎ;;; -> 인식 부족

엑티브 엑스가 지원 중단이 되면서 바뀐게 지금은 인증서 말고도 다른거 쓸 수 있음. 독점이 깨진거 뿐임.

솔루션에서 인증서 안쓰고 전자상거래 한다고 말하는데, 그거 사실 쓰는게 겉으로는 안보이는 거임 ㅎㅎ;;

 

1) 공개키 방식의 취약성

2) 공개키 암호화 방식 설명

3) 해커에 의한 중간자 공격

 

다. PKI의 구성

송신자와 수신자가 있음. A는 인증서를 만들어서 디렉토리에 등록 해야함. A는 등록기관(은행, 보험, 증원, 관공서: RA)에가서 자신의 신원을 확인함. 그리고 RA는 공인인증기관(금융결제원, 한국 정보 진흥원: CA)과 연결되어 있음. (그리고 그 위에 과학기술정보통신부 Root CA가 있긴 함) A의 공개키를 공개해야하는데, 은행창구를 통해서 신원확인하고 금융결제원에 보냄. 금융 결제원에서는 x.509에다가 A의 공개키를 넣고, 금융 결제원은 x.509인증서를 발행함. 그걸 받은 RA는 x.509를 A에게 배포, 공개해야하는 A의 공개키 x.509 CA의 비밀키로 암호화해서 디렉터리 서비스에 올림. A의 공개키가 필요한 B가 디렉터리 서비스에서 A의 x.509를 받아서 CA의 공개키로 복호화해서 A의 공개키를 받고, 그 공개키로 암호화한 평문을 A에게 보내 거래가 수행되게 함.

 

인증기관 = 공인인증기관임

-> 등록기관에 공개키 인증서를 발행, 갱신, 폐기도 함.

등록기관 = 은행창구

-> 개인에 공개키 인증서를 배포

디렉토리 

-> 인증서 및 인증서 취소 목록 

-> 누구나 디렉터리 서비스를 이용하여 x.509형식의 인인증서에 수납된 다른 사용자 및 인증기관의 공개키를 열람할 수 있다.

인증서

-> x.509인증서 사용 중. (여기엔 버젼, 일련번호, 유효기관, 식별자 등을 포함함)

-> 인증기관이 발행한 인증서는 공개키(A의 공개키)와 공개키의 소유자(A)를 공식적으로 연결해준다. 

인증서 취소 목록

 

공인인증서

전에는 공인인증이 독점이었는데, 지금은 다른 것도 쓸 수 있음~

 

 

1) 개요

라. PKI 특징

공개키를 그냥 공개하지 말고 금융결제원의 개인키로 암호화 해서 안전하게 관리하자. 

SET

인증서 폐지목록은 CRL이었는데 OCSP로 바뀜.

인증서는 공인 인증기관(CA)에서 발행한다.

등록기관은 은행창구임. 사용자랑 만나서 쎄쎄쎄함.

 

마. PKI 목표

기밀성, 무결성, 인증, 부인방지, 접근제어

 

바. PKI 구성요소

최소 객체 인증기관, 공인인증기관, 등록기관, 디렉터리 서비스, 사용자

가) 인증기관 : 금융결제원, CA

나) 등록기관: 사용자에 인증 요청 전송, 인증서 취소목록 검색, 인증서 취소 가

다) 디렉토리: 인증서 및 인증서 폐지 목록등 PKI관련 정보들을 보관

리) 사용자: 이것저것 함.

 

사. PKI 사용

보안을 위해,

공개키 방식을 써야하는데 중간자 공격에 취약하네? 그러면 공인인증서에 의해 공개키 보호 하자 PKI

그걸 이용한게 전자서명과 셋이 있음.

이메일, 원격접속, 전자문서, 전자상거래 등에서 사용함.

 

아. 공인인증서 방식의 자세한 설명

최소 객체에는 인증기관, 등록기관, 디렉터리, 사용자(A,B)가 필요함

인증서는 공개키를 제대로 관리하자

 

은행 창구에서 A의 신분증 확인하고 금융결제원에 A의 공개키를 보냄.

금융결제원에서는 A의 공개키를 x.509에 담음. (이 인증서는 금융결제원(CA)의 발행-> 등록기관(RA)의 배포를 통해 A가 다시 받음) 

금융결제원의 개인키로 A의 x.509를 암호화 함 -> 신원을 보증한다. 전자서명을 생성한다. 공개키와 공개키 소유자를 공식적으로 연결해 준다.

암호화된 인증서는 디렉토리 서비스에 공개하고, B가 A의 공개키가 필요하면, 디렉토리 서비스에서 A의 x.509를 받고, CA의 공개키로 복호화 하고 A의 공개키로 평문을 암호화해서 A에게 보내 거래가 수행ㅇ함.

 

디렉터리 서비스는 인증서가 폐기되면 CRL이라는 리스트에 추가가 됨. 근데 이 CRL이 무거워서 OCSP로 바뀌었음.

LDAP은 디렉터리 엑세스 프로토콜이고

SCVP는 인증경로 유효성 확인임.

 

1) 공개키 방식의 가장 큰 문제점은 공개키가 해커의 공개키인지 모름 -> 그래서 금융 결제원이 관리하자!가 됨.

2) A의 공개키를 금융결제원의 개인키로 암호화한거임. 

3) 공인인증기관이 발행한 인증서는 공개키와 공개키 소유자를 공식적으로 연결해줌

   -> 사용자 A의 공개키를 포함한 인증 정보를 공인증기관이 자신의 개인키로 암호화 한다. -> 전자서명 생성, 공개키와 공개키 소유자를 공식적으로 연결해준다.

4)

5) 공인인증서는 버전 일련번호, 서명, 식별자, 발행자, 유효번호 등이 있음.

6) 공인인증기관이 자신의 키(금융 결제원의 개인키)를 이용해서 전자서명을 생성한 후에 인증서에 첨부(x.509를 암호화)하고, 인증기관 키를 사용하여 인증서의 유효성을 확인한다.(디렉터리 서비스에 있는 A의 x.509를 복호화 하려면 금융결제원 공개키로 복호화가 되어야 함)

7) 표준은 x.509\8)

8)

9)

10) 공인인증서에 사용자의 개인키는 포함되나 공개키는 포함되지 않는다. 

 

 

자. PKI의 주요 관리 대상

가) 인증서

실제로 보면 걍 cmd화면 같음...

나) 전자서명법상 공인인증서에 포함사항

- 가입자 이름/법인명

- 가입자의 전자서명 검증정보(가입자의 공개키) x.509 인증서에 붙은 송신자의 공개키

   -> 전자서명 검증정보가 유출 되어도 공인인증서의 효력이 소멸되지 않는다 -> 어차피 공개키라 상관 

- 일련번호

- 전자서명 생성정보(공인 인증기관의 개로 암호화된 인증서 x.509)

 

1) 인증서 폐지 목록: CRL -> OCSP

효력이 정지되거나 폐지된 목록 관리, 

CRL이 파일 형태라 OCSP로 바뀜.

사용자는 내 파일이 최신인지 확인해야 함. -> CRL에 등록되어 있으면 폐지되었으므로 쓰면 안됨.

 

2) CRL 구조 -> 책에 없음. 나중에 공부해~

(1) CRL 기본 영역

(2) CRL 확장 영역 

 

차. 전자인증서(공인인증서 구조)

1) X.509

가) 개념

공개키(RSA) 기반의 인증 시스템 표준

구조는 버전, 일련번호, 알고리즘 식별자, 발행자, 유효기간, 주체(소유자), 공개키 정보, 서명 등의 정보가 들어있다.

나) X.500 시리즈 표준 목록

다) 인증서 프로파일

일련번호, 발급자, 유효기간, 소유자, 소유자 공개키, 발급자 및 고유자 고유 식별자 등 기본적인 사항 포함

실제로 키사에서 보면 쭉 있음. 인증서 프로파일 규격, 키사에서 인증서 열어볼 수 있음. 근데 봐도 뭐 없음;;

라) 인증서 기본영역의 필수항목

91p표 있음.

서브젝트 퍼플릭 키 인포 : 주체 공개키가 있음. 개인키는 없어용. 개인키는 개인들이 가지고 있어요. 주체의 공개키가 있음. 공인인증서에 사용자의 개인키는 포함되지 않아용.

마) 인증서 확장영역

기본이 있고 그 아래 확장이 있음. 네임 맵핑부터 해서 이것저것 있음. 

 

카. PKI 구성 프로토콜

1) LDAP -> 이런게 있다.

2) 온라인 인증서 상태 프로토콜: OCSP 

- CRL이 무거워서 나옴

- 인증서가 유효한지 아닌지 판단함.

3) 단순 인증서 검증 프로토콜: SCVP

 

타. 국내 공인인증기관

금융 결제원 뿐만 아니라, 증권 전산, 한국 전산원 등도 있음. 이 중 하나에서만 받으면 됨.

 

파. SPKI

심플 PKI도 있음. 근데 정부에서 귀찮아서 안함. 

 

하. XPKI

무선 공개 키 기반 구조 

휴대폰에서 쓰는데; 크게 차이 없음. 

 

3. 키 난수

가. 키

1) 개요

2) 세션키

3) 마스터키

 

나. 솔트

1) 개념

패스워드 저장할 때 해시 이용하는데 A의 패스워드가qweqert라면 이걸 해시함수로 바꾸면 고정값 해시함수가 나오겠지.

근데 만약 B의 패스워드가 A의 패스워드와 같다면 해시값이 같을테니, 이걸 방지하고자 패스워드에 무작위 문자열을 중간중간 추가해서 해시값을 다르게 한다. -> 진짜 소금치는거;;

의사난수 생성기로 만들어지는 랜덤한 수

솔트는 사전 공격을 막기 위해 존재함. 패스워드를 리스트로 만들고 무차별 공격은 될 때까지 하는거라 효율이 낮음. 

근데 사람들이 쓰는 패스워드는 한정되어 있다. 그걸 쓰면 효과적으로 공격이 되더라.

 

2) 특징

의사 난수

 

다. 난수

1) 개념

주사위는 확률이 1/6임 천만번 던지면 확률이 1/6이겠지만, 2번만 던졌을 땐 1/6이 아니지.

컴퓨터가 만드는 난수는 난수가 아님. 컴퓨터의 난수는 패턴이 나옴;; 함수라서.

하지만 난수는 주사위처럼 뭐가 나올지를 짐작할 수 없음.

 

가장 훌륭한 난수는 자사위 100개를 던져서 나오는 것이 난수지.

 

월드컵 승부차기, 골대 오른쪽으로 공을 참, 박지성도 오른쪽으로 참, 설기훈도 오른쪽으로 참. 안정환도 오른쪽, 마지막도 오른쪽...!... 골키퍼는 모두 왼쪽으로만 몸을 날렸다...!.... -> 물론 이건 난수가 아님. 

 

2) 난수의 성질

무작위성, 예측 불가능성, 재현 불가능성

3) 난수의 용도

 

4) 의사난수

컴퓨터가 만드는 난수 -> 난수는 아니고 난수를 흉내낸거임. (커다란 주기를 만들더라) 

생성된 수열의 어느 부분 수열도 다른 부분 수열로부터 추정될 수 없어야 한다. 

 

양자 컴퓨터로 하면 추정이 가능하다고 함...!

 

 

양자컴퓨터라는데

뭔가.. 21세기를 상상하며 만든 sf영화에 나올거 같은 비주얼인데