컴퓨터 보안 (11) - Cryptography2 (完)

시험공부하며 러프하게 정리한 내용이니, 가볍게 참고만 하시길

 

🥕10장 Cryptography2

여기는 비대칭 키의 메세지 기밀성 부분임

>> 대칭 암호의 문제 (키 배송 문제) 해결법
- 키를 사전에 공유
직접 배달은 안전, 사람 많아지면 관리해야할 키가 너무 많아짐

- 키 배포센터 (KDC) 이용
암호 통신 때마다 KDC에 의뢰하여 키 공유
센터 컴퓨터 고장시 조직 전체 암호통신 마비
KDC 자체가 공격 타겟이 됨

- Diffie-Hellman 키 교환
일부 정보만(g^a, g^b) 교환, 그걸 가지고 각 사람이 같은 키를 생성해냄
ex) g^a, g^b을 보내놓고 g^ab이라는 키를 만들어냄. 이브가 도청해도 g^a, g^b만 가지고는 g^ab를 구하긴 어려움. 저 두개 곱해도 g^(a+b)니까

- 공개키 암호 사용
송신 : 공개키로 암호화 해서 보냄 (랜덤키로 암호화)
수신 : 개인키로 복호화 해서 봄

>> key 개수
- 대칭암호                   : N명일 때 N*(N-1) / 2 개의 key 필요
- 비대칭 암호 (공개키) : N명일 때 2N개 키가 필요 (공개키-개인키 쌍으로 N개 pairs)

>> 공개키
- 공개키, 개인키는 한 쌍이고 공개키로 암호화한건 반드시 짝꿍 개인키만 복호화가능
- 공개키와 개인키 쌍은 별개로 만들 수 없음.
- 공개키는 도청당하든, 읽게하든 상관 없음.
- 개인키는 보여주면안되고, 심지어 통신하는 상대에게도 보여주면 안됨.

>> 공개키 종류
- EIGamal 방식 : 이산대수 구하는 거 어렵다는 것 이용 (a^x)
- RSA 방식 : 큰 수의 소인수분해 어렵다는 것 이용
- 타원곡선암호 : 곱셈의 역연산이 어렵다는 것 이용

>> 공개키로 해결할 수 없는 문제
1. Man in the middle attack : 공개키가 정말 상대가 보낸 게 맞는가 ?? 해커의 공개키는 아닌가?
2. 느리고 크다 : 대칭 암호에 비해 암/복호화가 몇백배나 느리고, 암호문의 크기도 평문에 비해 엄청 커짐.
→ 하이브리드 암호 시스템으로 해결

>> 하이브리드 암호 시스템 : 대칭키 + 공개키
(공개키 알고리즘이 긴 평문이 아니라, 짧은 키를 암호화하는 거라서 단점을 해결한 것이라고 이해함)

- 구성요소 3가지
1. 대칭암호 : 기밀성 유지한 통신 가능, 빠르게 암호화 가능 but 키 배송이 문제
메세지 암호화에 사용
충분히 길이가 긴 키를 사용해야함
적절한 블록 암호 모드를 사용해야함

2. 공개키암호 : 키 배송 안하지만, 느리고 중간자 공격에 약함
세션키 암호화에 사용.
충분히 길이가 긴 키를 사용해야함

3. PRNG : 대칭암호에서 사용하는 세션키 만들어줌.
세션키의 품질이 나쁘면(ex. 0이 많은 경우) 세션키를 추측할 수 있고 일부 비트라도 추측되지 않게 주의.

- 복호화 방법 
분리 : 대칭키로 암호화된 암호문이랑, 공개키로 암호화된 세션키를 분리함
세션키를 개인키로 복호화
메세지를 세션키로 복호화

- 하이브리드 암호화 예시
PGP : 전자서명, 전사서명 검증 등에 사용
SSL/TLS : WEB 암호 통신에서 사용 (https)

>> 하이브리드 암호 시스템의 밸런스 (3개의 강도 밸런스가 필요. 대칭과 공개 암호는 강한 알고리즘 사용)
- 한쪽의 키 길이가 짧으면 그쪽만 공격당함
- 대칭암호와 공개키 암호는 충분히 길게 해야함 양쪽이 같은 정도의 강도가 되게 길이 균형 맞춰야함.
- 장기간 운용할거라면 대칭암호보다 공개키 암호쪽을 강하게 하는게 좋음.
----------------------------------------------------------------------------------------
메세지 기밀 유지 기법은 끝
이제부턴 데이터 무결성 검증 방법 함 → MAC 이용

>> Message Authentication Code (MAC)
암호화했다고해서 무결성 보장되는 건 아님.

- 대칭키 요소
MAC도 대칭키인데, 태그 만드는 키와 검증하는 키가 같음.

- 구성요소
랜덤키, 랜덤태그, 검증알고리즘으로 최종 메세지 변경 여부 검증 (must be deterministic)

- 유효한 메세지, 태그 쌍을 만들 확률이 무시할 수 있을 정도로 작다. (태그를 무작위로 만들기 때문에)

>> MAC 예시 : Hash MAC (HMAC)
- Hash 특징
1. 임의 크기 입력에 대해 항상 같은 크기 출력 생성 (입력에 비해 출력이 작다. 압축된 형태)
2. 서로 다른 입력으로 같은 해쉬 찾기 어려움 (충돌나기 어렵)
3. 출력이 랜덤해서 추측 불가능
4. keyless 키없이도 암호화 가능
5. 아웃풋 가지고 인풋 추측하기 어려움 (one wayness)
(충돌저항성이 곧 일방향성 ?)

- Hash 충돌
output 사이즈가 128bit 해시일 때, 2^64번 시도하면 충돌이 날 수 있다는 뜻.
해시 충돌을 통한 공격을 방지하기 위해, 큰 출력 bit를 가져야함. 256 이상이면 안전하다.

- HMAC에서 Tag = Hash(key, message) 새로운 메세지로 이 Tag값 알아내기는 거의 불가능.
- 공격자가 key를 모르면 새로운 메세지로 Tag 값 찾기 거의 불가능.
- hash도 블록단위 연산이라 무조건 안전하다고는 못함.
(실제로는 더 복잡하게 함. 해시 2번쓰기 등)
----------------------------------------------------------------------------------------
이제부턴 데이터 인증 방법 함 → 전자서명 이용 (비대칭키)
(정말 앨리스가 보낸 데이터가 맞나?)

>> MAC의 문제점
대칭키라 수신자도 key를 알고 있으니 이 데이터가 앨리스에게 왔다는 걸 다른 사람들에게 증명할 수 없음.
수신자도 key를 아니까 위조할 수 있는 것 → 앨리스가 저한테 100만원 준다고 했다고요 !! 여기 싸인 있잖아요 !! (위조된 싸인)

>> 전자서명의 비대칭키 요소
- 태그를 만드는 키와, 검증하는 키가 서로 다름.
- 태그 생성 : 서명키 (sk, 비밀키 역할)
- 태그 검증 : 인증키 (vk, 공개키 역할)
이 키들은 랜덤하게 생성된 한 쌍임

>> 전자서명  vs  MAC
- 전사서명은 누구나 검증할 수 있음.
- 파티가 같은 키를 공유해서 인증함.
- 전자서명은 비밀키라서 앨리스만 할 수 있음. 그래서 부정 못함.
- 근데 MAC에서 태그는 앨리스가 부정할 수 있음. 대칭키니까 밥이 자작할 수도 있음.

>> 전자서명
- 메세지, 서명 계속 관찰해도 비밀키 없어서 서명을 못함.
- 새로운 메세지에 대해서 서명을 시도해서 맞출 확률이 무시할정도로 작다.