오래 못 할 짓 하지 않기
[ 컴퓨터 보안 ] 18. Internet Security Protocol 본문
[ 컴퓨터 보안 ] 18. Internet Security Protocol
쫑알bot 2024. 11. 26. 12:04
Internet Security Protocol
Web Traffic 내에서 Security를 보장하는 방법
각각의 Level마다 Security를 추가하는 방법이 다르다.
위와 같이 전송 계층을 생각해보면 위에서 3개의 층을 살펴보면
Network / Transport / Application 레벨에서 위와 같은 Security 기능을 추가할 수 있다.
Secure Socket Layer SSL
Transport Layer의 Security를 담당하는 서비스로서
TLS(Transport Layer Security) 의 기본 구성요소가 되었다.
- Record Protocol : Message Enc/Dec나 MAC을 만드는 과정이 이루어지고, 데이터의 무결성을 검사하는 역할을 수한다.
- Handshake Protocol : Client ↔ Server 사이에 연결을 담당한다.
- Change Cipher Spec Protocol : 암호화 과정에서 쓰이는 Param을 변경하는 곳
- Alert Protocol : 연결 상태 모니터링 후 알려준다.
이러한 SSL/TLS Layer는 Transport 와 Application Layer 사이에 들어간다.
[ SSL/TLS Layer의 역할 ]
1. Data 를 Encryption + Authority 인증까지 해주기 때문에 Data Confidential을 보장한다.
2. 그 과정에서 대칭 / 비대칭 / Digital Signature 을 사용한다.
= Web Secure Connetion에 많이 쓰인다.
SSL 연결 및 프로세스
[ SSL Connection ]
: Client나 Server의 개념이 없다.
Peer-to-Peer 식으로 간다. = A와 B가 연결됐음!
세션 안에 여러 Connection이 들어가있다.
[ SSL Session ]
Client나 Server의 개념으로 작동한다.
- Handshake를 통해 돌아간다.
- 암호화 시키기 위한 Parameter를 정하여, 이를 주고받으며 보안 유지한다.
- 한 Session 안에 여러 Connction들을 가지고 있는다.
- Session에서는 한 쪽이 Client, 다른 한 쪽이 Server
- Connection으로 보면 둘 다 같은 Peer
[ SSL Handshake Protocol ]
: Client와 Server가 각각 서로에게 Authenticate할 수 있게 해준다.
* Handshake 과정에서 [ 어떤 Encryption , MAC 알고리즘 , KEY 를 사용할지 ] 정한다.
> Application으로 보내기 전에 Handshake Protocol을 지난다.
📌 Handshake 과정
1. Security 와 관련하여 어느 정도까지 수용할 조건이 되는지 맞춘다.
2. Server가 본인에 대한 Authentication(Certificate) 와 Key를 보낸다.
3. Client가 본인에 대한 Authentication(Certificate) 와 Key를 보낸다.
4. 교환이 끝난다.
참고로 이 SSL Handshake 과정은
이들이 이미 3way handshake를 통해 연결이 되어있다는 가정 하에
추가적인 Security Connection을 위한 소통 작업이다.
그럼 아래에서 자세하게 들여다보자.
1. Establish Security Capabilities
[ Client_Hello ]
- Version : Client가 보낼 수 있는 가장 높은 version의 SSL
- Random number : 32bit (Time stamp) + 28 Random bytes --> 그냥 서로 암구호 같은 거라고 생각하자.
- Session ID : 새로운 Session에서 새로운 Connection인지. ( 기존에 session이 존재했다면 0은 아닐 것이다.)
- Chipher suite : 암/복호화 알고리즘을 어떤 순서로 시킬건지. (DECS Preference) + key exchange + CipherSpec
- Compression Methods
[ Server_Hello ]
- 위에 Client가 보내는 것과 거의 다 같음.
대신 Confirm하는 메시지임
+ Client가 보낸 Version중에 Server가 Support할 수 있는 공통 Verison을 보낸다.
+ 새로운 Random number
+ Session ID는 받은 게 0이면 그대로, 아니면 새로운 걸로.
암호화 방법이나 MAC을 위한 Hash 방법은 다양하다.
다 외울 필요는 없고 DES도 있고, SHA도 있다 정도만 알고 넘어가자.
[ 1단계가 끝나면 알게 되는 것 ] --> 이런 거 나올 거 같음
- [ Key + Message 인증 + Encryption + Compression 를 할 때 어떤 알고리즘 ] 을 사용하는지
- Key 생성을 위한 Random number
2. Server Authentication and Key Exchange
[ Server가 보내는 것 ]
1. Certification : X.509 certificate Chain을 보낸다. 그냥 열쇠꾸러미 보내는 느낌같음,
Server : " 나 믿을만한 놈임 , 이렇게 인증서도 발급받았음. "
단, Anonymous Diffie-Hellman 방식에서는 이 과정이 필요없다.
2. Server_key_exchange : Server에서 Public Key를 준다.
단, Exchange method로 RSA 혹은 Fixed DH를 쓰면 이 과정이 필요없다.
- RSA : Key 교환에 필요한 정보가 이미 인증서에 포함되어 있음
- Fixed Diffie-Hellman : 키 관련 교환 매개 변수를 이미 가지고 있음
3. Certificate_Request : Server가 Client에게 너도 인증하라고 Request을 보냄
- 서버가 수락 가능한 인증서 Type
- " " 인증 기관 (CA) 를 함께 넣어서 이 양식에 맞게 달라고 함
4. Server Hello Done = 다 보냄
a. RSA에 Server의 Public key가 있으니까 Key exchange X
b. Man in middle 공격에 취약할 수 있다.
c. Public Key는 이미 있음. Key exchange할 때는 Signature를 추가해서 보낸다.
그럼 그 Signature를 Public key로 열어서 보고 가장 안전하게 전달할 수 있다.
d. certificate 를 DH 알고리즘 값을 담아서 준다. Session 을 계속 유지할 수 있다.
모든 세션에 대해서 계속해서 같은 Key를 쓴다. 약간 취약
[ 2단계가 끝나면 알게 되는 것 ]
- Client 입장에서 Server가 Authenticated됨
- Client가 Server의 Public Key를 알고 있음.
3. Client Authentication and Key Exchange
1. Certificate : Server가 Certificate를 요청했을 경우에만 전송한다.
2. Client_key_exchange : Client가 pre-master secret key를 생성한다.
→ server가 보냈던 Public key로 Encryption한다.
→ server에게 보낸다. = Server의 Pulbic Key로 했으니까 Server 본인만 그걸 Decrypt해서 볼 수 있다.
3. Certificate Verify : Client 본인의 Private Key로 만든 Certificate를 Server에 보내 인증하는 과정
[ 3단계가 끝나면 알게 되는 것 ]
- Server 입장에서 Client가 Authenticated됨
- Client와 Server 모두 Pre-master Secret 을 알고 있음.
4. Finish
Client / Server(얘는 그냥 Send back) :
- Change_Cipher_Spec Message를 보낸다.
> 지금까지 주고받은 알고리즘/Key 관련해서 협상한 내용로 잘 포장해서 메시지를 전달하겠다는 Message
" 이제부터 우리가 합의한 새로운 암호화 방식을 적용할게요 "
- Finished Message를 보낸다.
> "지금까지 주고 받았던 정보들 중에서 문제가 없었다." 라고 Integrity 알려주는 메시지
+ Hash값을 저장해두었다가 그걸로 보낸다.
<------------------------- 여기까진 암호화 안 하고 주고받음 -------------------->
[ 4단계가 끝나면 ]
이제 서로 데이터를 주고 받을 준비 끝
Key 생성에 대해
Pre-master -> Master -> Key material 로 간다고 이해하면 빠르다.
- Secure Key Exchange (RSA / Diffie-Hellman) 를 통해 Master Key를 만들고
- 그 Master Key를 가지고 Key나 IV등을 생성한다고 볼 수 있다.
Hash [ (Pre) Master Secret + Clnt 랜덤값 + Server 랜덤값 ]
> 이렇게 나온 값을 h1이라고 하자.
그런 뒤에 Hash ( h1 , (Pre) Master ) 한 값이 그 다음 결과Master Secret or Key Matrial 가 된다.
SSL Record Protocol / Alert Protocol
📌목적 : Confidentiality , Message Integrity
데이터 기밀성과 Integrity를 위한 기능을 한다.
[ 작동 방식 ]
1. 원본 데이터를 여러 조각으로 쪼갠다.
2. (필수는 아님) 그 조각을 Loss없이 압축시킨다.
3. 그 압축시킨 값을 기반으로 MAC을 덧붙인다. MAC = hash(MAC_write_secret,pads,seq_num)
*HMAC과 비슷한 개념이다.
4. Encryption ( Compression + MAC )
5. SSL Record Header를 덧붙인다. (내용: Content Type , alert, Change Cipher)
SSL Change Cipher Spec Protocol
이제 다 관련된 Key값을 서로 주고받고, ' 이제 그걸 쓸 타이밍인지, 아닌지' 를 판단하는 1byte (Flag) 느낌임
그래서 아직 Change Cipher Spec 이 On되지 않은 경우에는
받은 Key값들이 모두 Pending 상태로 있다.
Handshaking 4단계에서 change cipher spec을 거친 뒤에는
change cipher spec을 거친 뒤에는그 Param을 사용할 수 있기 때문에
계산해두기만 한 Spec들을 Active table로 옮겨서 실질적으로 사용 가능하다.
서로 줄 때 쓰는 Param과 받을 때 쓰는 Param이 있다.
Server가 Write하는 Param
= Client가 Read하는 Param
- Alert
주로 하는 역할은 Warning과 Fatal을 알려준다.
[ Fatal ]
- 예상치 못한 메시지
- Bad Record Mac
- 압축해제 실패
- Handshaking 실패
- Illegal Param
[ Warning ]
- Close notify
- No/bad/unsupported certificate
.. 주로 Certificate 관련 + 연결 종료면 여기임
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
한동대학교 고윤민교수님 - 컴퓨터 보안
