일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- css
- kmip
- 2FA
- albumbook
- 앱스토어
- 인증
- otpkey
- 애플
- SSH
- FIDO2
- 안드로이드
- MSYS2
- OSX
- fido
- 앱리소스
- 앨범북
- Xcode
- git
- MYSQL
- Nodejs
- SWIFT
- MFA
- WebAuthn
- openssl
- SSL
- appres
- SwiftUI
- apple
- Android
- OTP
Archives
- Today
- Total
인디노트
[Kisa] 암호의 이해와 키 관리 실무 - 1일차 (암호학의 기초) 본문
1일차 암호학의 기초
Kerckoff : 결국, 암호 알고리즘을 알아도 키를 모르면 깰 수 없도록 해야 한다.
대칭키
XOR : 같으면 0, 다르면 1
OTP - One Time Pad ( 암호화 )
- 키 길이와 평문의 길이가 동일함.
- 가장 빠르고 가장 안전한데 비효율적.
OTP - One Time Password ( 인증 )
블럭 암호화 (DES, 3DES, Blowfish, AES, SEED ...)
- 암호문의 길이는 블록의 배수 ( 16Byte 블록이라면 1Byte 암호화해도 16Byte가 나옴 )
패딩 : 0x남은게 몇 비트인지?
단, 패딩 리무버는 반드시 작동하므로, 평문이 딱 블록의 배수가 된다고 해도
블록 단위가 16Byte 일 때 16을 16개로 채워서 복호화 하는 사람을 배려 한다.
(즉, 16Byte 를 암호화 해도 32Byte 가 나온다.)
스트림 암호화 (RC2, RC4 ...)
- Key -> Key Derive Function -> Key Stream . 이후 1bit 씩 암호화
AES
- AES 192, AES 256 Bit 의 안정성이 실제 키 사이즈 보다 낮음을 증명
특히 AES 256 은 오히려 AES 128 보다 낮다.
https://eprint.iacr.org/2009/317.pdf
DES - Feistel 구조
- 암호화와 복호화 로직이 동일함. 다만 키 스케줄링 순서가 반대일 뿐
- 그렇다면 대칭성을 가진 키가 있다면 ? 암호화 한번 더 하면 자연히 복호화 된다.
- Brute Force 에 취약하다고 밝혀져 3-DES 가 나오게 됨.
암호화 모드 (https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation)
IV - CBC, CFB, OFB, CTR
암호문의 길이를 평문 길이에 맞춤 : CFB, OFB, CTR
암호문 변조 확인 : GCM, CCM
CBC : 그것만 없으면 가장 안전함.
ECB 모드(Key, Padding) : 상당히 짧은 데이터를 암호화 할 때 정도만 쓰인다.
왜냐하면 한개의 블록만 해독되면 나머지도 해독 됨.
CBC 모드(Key, IV, Padding) : 가장 안전하고 가장 많이 쓰는데 ...
PKCS5 패딩 오류가 결합되면 가장 취약함.
처음 IV로 XOR 하고 키 알고리즘으로 암호화 한다.
이후는 나온 암호문 블록이 IV가 되서 반복한다.
CFB 모드(Key, IV, NOP) : CBC 다음으로 안전한데, 구현이 좀 어렵다.
블록 암호화를 스트림 암호화 처럼 구성해 Padding 필요 없음
IV를 암호화 한 다음 스트림 단위로 자르고, 평문이랑 XOR 한다.
이후 이 스트림이 다시 IV가 됨.
OFB 모드(Key, IV, NOP) : 한번 더 암호화 하면 평문 나와서 취약함. 좀 속도가 빠르긴 함.
Padding 필요 없음
CTR 모드(Key, IV, NOP): 한번 더 암호화 하면 평문 나옴.
다만 이렇게 되지 않도록 Shift 등, 보완해서 쓴다.
다른 모드에 비해 평문 수정이 쉽다.
IV를 1씩 증가시켜서 암호화 시킨 다음, 평문과 XOR 한다.
GCM 모드(Key, IV, AAD, NOP) :
CTR과 동일한데,
Additional Auth Data 로 암호문 블록을 계속 XOR 해서 Auth Tag를 만들어 낸다.
이걸로 무결성 검증이 가능하다.
CCM 모드(Key, Nonce, AAD, Tlen, NOP)
CTR과 동일한데 안쓴다.
문제 : IV 를 찾아라 !
암복호화 엔진을 변경하려고 하는데, CBC모드를 사용하고 있어
기존에 사용되던 Key 와 IV를 알아내야 한다.
그러나 IV는 해당 엔진 내에 화이트박스 처리 되어있어 알 수 없는 상황.
즉,
Encrypt (Key, IV, 평문) -> 암호문
이 아니라
Encrypt (Key, 평문) -> 암호문
이렇게 CBC 모드의 IV 가 함수 자체에 내장되어 있는 경우 어떻게 IV를 찾는가?
기존에 사용되던 Key 와 IV를 알아내야 한다.
그러나 IV는 해당 엔진 내에 화이트박스 처리 되어있어 알 수 없는 상황.
즉,
Encrypt (Key, IV, 평문) -> 암호문
이 아니라
Encrypt (Key, 평문) -> 암호문
이렇게 CBC 모드의 IV 가 함수 자체에 내장되어 있는 경우 어떻게 IV를 찾는가?
0을 CBC 로 암호화 하게되면
0 XOR IV == IV -> enc (IV)
따라서 다시 ECB dec 하면 IV 가 나오게 된다.
Oracle Padding (CBC)
패딩 오류가 안나고 통과할 때 까지 두번째 블록을 변경해서 날려본다.
결론 : AES 128bit GCM 쓰면 된다.
비대칭키
RSA (2048) : 소인수 분해. 암호화, 전자서명
DSA (1024) : 이산대수. 전자서명
DH (1024) : 이산대수. 키 교환
ELGamal (1024) : 이산대수. 암호화. 전자서명
ECDH (256) : 타원곡선 상의 이산대수. 키 교환
ECDSA (256) : 타원곡선 상의 이산대수. 전자서명
KCDSA (1024) : 이산대수. 전자서명
키 길이가 괄호 bit 이상이면 안전하다 라고 알려져 있음.
적당히 작은 e를 써야하는데 65537 을 쓴다. 너무 작은 값을 사용하면 취약하다.
RSA - 암호문은 확률적으로 계속 변경된다. 어떻게?
( 하나의 평문에 대응하는 암호문이 많다 )
-> 패딩을 쓰레기값으로 넣어줘서 전체 값이 랜덤하게 변경되도록 한다.
10 G 메시지가 있다고 치자.
이거 RSA로 암호화 하면 너무 오래걸린다. -> 해시해서 쓴다.
MD5 - 알고리즘 자체에 취약점이 발견되어 사용 불가.
SHA1 에서 2^80 메시지만 갖고 있어도 100% 충돌을 발견 할 수 있다.
전자 서명에서 사용 할 수 없다.
SHA2 에 256비트 많이 쓰는데 알고리즘 취약점이 나올 확률이 있다.
SHA3 - SHA2 보다 3배정도 느리지만 앞으로 많이 쓰일 것으로 보인다.
서명 : 메시지를 해시 하고 개인키로 암호화해서 메시지와 함께 보내면
공개키 연산이 더 빠르다 -> 작은 소수를 썼기 때문이다.
Random Generator 가 실제 난수가 아니기 때문에
컴퓨터가 랜덤한 Seed 를 만들지 못하고 Sha 도 다양성이 낮으면
낮은걸 따라가므로 128비트 정도의 안정성 밖에 없다.
반응형
'인증기술' 카테고리의 다른 글
[Kisa] 암호의 이해와 키 관리 실무 - 4일차 암호와 금융 보안 (0) | 2018.05.05 |
---|---|
[Kisa] 암호의 이해와 키 관리 실무 - 3일차 정보보안 Compliance (0) | 2018.05.05 |
[Kisa] 암호의 이해와 키 관리 실무 - 3일차 PKI 관련 표준 - PKCS (0) | 2018.05.05 |
[Kisa] 암호의 이해와 키 관리 실무 - 2일차 PKI와 관련 표준의 이해 (0) | 2018.05.05 |
X.509 인증서 파일 이름 확장명 (0) | 2018.03.30 |
Comments