Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a 공인인증서 크래킹 - Inc0gnito 2015
Similar a 공인인증서 크래킹 - Inc0gnito 2015 (20)
공인인증서 크래킹 - Inc0gnito 2015
- 1. 공인인증서 크래킹 KUICS 장하진 For 4th Incognito 2015.08.27
- 2. 발표자 소개 • 고려대학교 컴퓨터학과 2학년 재학생 • KUICS 12대 회장 • (http://kuics.korea.ac.kr) • Best of the Best 4기 교육생 2015-08-27 KUICS2
- 3. Thanks to • KUICS 이준혁 OpenCL에 갈리셨습니다. 2015-08-27 KUICS3
- 4. 목차 • 1) 현대암호 개론 • 2) 대칭키 암호 • 3) 비대칭키 암호 • 4) 해시함수 • 5) 공인인증서 구조 • 6) 암호문 공격기법 • 7) 공인인증서 크래킹 2015-08-27 KUICS4
- 5. 현대암호 개론 막아! 뚫어! 막아! 뚫어! 2015-08-27 KUICS5
- 6. 고대암호 vs 현대암호 고대암호 • 암호문에서 원문 유추 가능 현대암호 • 암호문에서 원문 유추 불 가 ABCD HIJK e98b5c61c1a162ab e3e02157d02a57d2 현대 암호는 수학적 원리를 바탕으로 한다. 2015-08-27 KUICS6
- 7. 현대암호 - 암호화의 종류 양방향 암호화 • 암호문을 다시 평문으로 복원할 수 있다. • 가역적 • Encrytion 단방향 암호화 • 암호문을 다시 평문으로 복원할 수 없다. • 비가역적 • Hashing 2015-08-27 KUICS7
- 8. 양방향 암호화 대칭키 암호 • 암호화 키 == 복호화 키 • 빠른 속도 • DES, AES • SEED, ARIA • RC4 공개키 암호 • 암호화 키 != 복호화 키 • 느린 속도 • RSA • ECC (타원암호) 2015-08-27 KUICS8 (== 비대칭 키)
- 9. 대칭키 암호 디지털 세계의 범용 자물쇠 2015-08-27 KUICS9
- 10. 대칭키 암호 (Symmetric-key) • 암호화할 때 쓰는 키와 복호화할 때 쓰는 키가 같다. • 비교적 연산의 양이 적으며, 계산이 빠르다. • 스트림 암호와 블록 암호로 나뉘어진다. • 공인인증서에는 블록 암호가 사용된다. 2015-08-27 KUICS10
- 11. 스트림 암호 (Stream Cipher) • 한 번에 한 비트나 한 바이트 단위로 암호화한다. • 블록 암호보다 일반적으로 빠르다. • 블록 암호보다 일반적으로 낮은 보안성을 가진다. • 네트워크 송수신, 스트리밍 암호화 등에 사용 • Ex) RC4 2015-08-27 KUICS11
- 12. 블록 암호 (Block Cipher) • 한 번에 특정 바이트(블록) 단위로 암호화한다. • 정해진 크기의 입력만 받을 수 있으므로 블록 단위로 메시지를 나눠서 암호화 • 스트림 암호보다 일반적으로 느리나, 보안성은 더 높 다. • 가장 대중적으로 쓰이는 암호화 종류 • Ex)DES, AES, SEED, ARIA 2015-08-27 KUICS12
- 13. SEED • 1999년 2월에 KISA 주도로 만들어진 128비트 블록 암호 알고리즘 • 2005년에 국제 표준화 기구 ISO/IEC에서 국제 블록 암호알고리즘으로 등록 • 2009년에 256비트 키를 지원하는 SEED 256 개발 • 1990년 당시 미국은 40비트 이상의 암호화 기술의 수출을 금지 • -> 공인인증서는 SEED 128비트 알고리즘을 사용한 다. 2015-08-27 KUICS13
- 14. 패딩 (Padding) • 블록 암호의 경우, 정해진 길이의 입력만 받을 수 있 다. • 하지만 암호화할 메시지의 길이는 다 제각각이다. • 따라서, 메시지의 길이를 블록의 배수로 맞춰주기 위 해 정해진 규칙에 따라 ‘패딩’를 덧붙인다. 2015-08-27 KUICS14 j o v e l e r j o o n j i j o v e l e r j o o n j i 3 3 3
- 15. 패딩의 종류 • Zero Padding • ANSI X.923 • PKCS#7 (== PKCS#5) 2015-08-27 KUICS15 s l e e p y j o v e l x0 0 x0 0 x0 0 x0 0 x0 0 s l e e p y j o v e l x0 0 x0 0 x0 0 x0 0 x0 5 s l e e p y j o v e l x0 5 x0 5 x0 5 x0 5 x0 5
- 16. 암호화 모드 (Cryptographic Mode) • 블록 암호에서 각각의 블록의 관계를 어떻게 처리할 까? • Mode of Operation (운영방식) 이라고도 불린다. • Ex) ECB, CBC • Ex) CFB, OFB, CTR • 간단하게 하나로 통일하지 왜 여러 개를 만들었을까? 2015-08-27 KUICS16
- 17. 암호화 모드 - ECB • Electronic Codebook • 각각의 블록이 독립적으로 암호화된다. 2015-08-27 KUICS17
- 18. 암호화 모드 - ECB • 암호화 모드 중 구조가 가장 단순 • 각각의 블록이 독립적으로 복호화된다. 2015-08-27 KUICS18
- 19. 암호화 모드 - ECB • 그런데? • 같은 입력이 들어가면 반드시 같은 결과가 나온다. • 암호문에서 각각의 블록 사이의 관계를 유추할 수 있 다. • -> 취약하다! 2015-08-27 KUICS19
- 20. 암호화 모드 - CBC • Cipher Block Chaining • 직전 블록의 암호문이 다음 블록을 암호화할 때 쓰임 • IV의 존재 2015-08-27 KUICS20
- 21. 암호화 모드 - CBC • 직전 블록의 암호문이 다음 블록을 복호화할 때 쓰임 • 암호화할 때는 병렬처리를 할 수 없다. • 복호화할 때는 병렬처리를 할 수 있다. 2015-08-27 KUICS21
- 22. 암호화 모드 - CBC • ECB vs CBC • 같은 입력이 들어가도 다른 결과가 나온다. • 암호문에서 각각의 블록 사이의 관계를 유추할 수 없 다. • -> 가장 대중적으로 쓰이는 암호화 모드 • -> 공인인증서도 이 CBC 모드를 사용 2015-08-27 KUICS22
- 23. 비대칭키 암호 디지털 세계의 특수 자물쇠 2015-08-27 KUICS23
- 24. 비대칭키 암호 (Public-key) • 암호화할 때 쓰는 키와 복호화할 때 쓰는 키가 다르 다. • 개인키와 공개키가 쌍으로 존재하며, A-B가 쌍인 경 우 A로 암호화하면 B로밖에 풀 수 없고 B로 암호화 하면 A로밖에 풀 수 없다. • 공인인증서의 주 기능인 ‘전자서명’은 이 비대칭키 암호의 원리에 기반한다. • Ex) RSA, ECC 2015-08-27 KUICS24
- 25. 비대칭키 암호 • 개인키와 공개키를 쌍으로 생성한다. • 개인키는 안전하게 자신만이 가지고 있고, 공개키를 외부에 공개한다. • 서로 공개키를 교환한 후, 상대방의 공개키로 정보를 암호화해서 보내면 상대방만이 이를 열어볼 수 있다. • -> 언제나 도청당할 수 있는 인터넷에서 정보를 안전 하게 주고받을 수 있게 해준다. 2015-08-27 KUICS25
- 26. 비대칭키 암호 • 상대방에게 자신의 공개키를 알려준 후, 자신의 개인 키로 특정 정보를 암호화해서 공개하면 “내가 이 정 보에 서명했다”는 것을 입증할 수 있다. • (나의 공개키로 풀리는 정보는 오직 내 개인키로 암 호화한 정보 뿐이다!) • -> 전자서명의 이론적 토대가 된다. • -> 공인인증서의 “부인방지” 특성은 비대칭키를 기반 으로 한다. 2015-08-27 KUICS26
- 27. 비대칭키 암호 • 하지만… • 대칭키 암호에 비해 복잡하고 속도가 현저히 느리다. • 대칭키 암호와 공개키 암호는 상호 보완적이다. • 인터넷에서 정보를 주고받을 때는 대칭키와 비대칭 키를 섞어 사용한다. • Ex) SSL, https 2015-08-27 KUICS27
- 28. RSA • 가장 대표적으로 널리 쓰이는 공개키 암호. • 두 소수를 알고 있으면 곱은 구하기 쉽지만, 매우 큰 수를 소인수분해하기는 어렵다. • 두 소수를 이용해 개인키, 공개키를 생성한다. • 약방의 감초 2015-08-27 KUICS28
- 30. 해시함수 디지털 세계의 지문 2015-08-27 KUICS30
- 31. 단방향 암호화 • 암호화를 하면 평문으로 되돌릴 수 없다. • Hash 함수가 여기 속한다. • 해시함수란? • 임의의 길이를 갖는 문자열을 입력 받아 고정된 길이 의 해시값을 출력하는 함수 • 역함수가 존재하지 않는다 • 디지털 세계의 지문 2015-08-27 KUICS31
- 32. 해시함수 • 해시함수의 종류 • Ex) MD4, MD5, SHA1 • Ex) SHA256, SHA512, SHA3 • 해시함수의 특징 • 눈사태 효과 • 해시충돌(Collision) 발생시? 7f7eb2b2 CrackMe X CrackME 9fc8912a X ≠ 2015-08-27 KUICS32
- 33. Hash의 예시 • “HelloHash” 문자열를 해싱하면? • MD5 • b884835e390cca19ca121f9af942e786 • SHA1 • af46d07e711fdd8d4821de03f30b1af8e9680555bfb 4c4d2f21b7b11397648ab • Hash 값만 가지고 원래의 값을 알 수는 없다. 2015-08-27 KUICS33
- 34. 해시함수의 활용 및 전제 • 해시함수의 활용 • 비밀번호 DB 암호화 • 파일의 무결성 검사 • 빠른 전자서명 • 해시함수의 전제 • 충돌을 최대한 피하자! 2015-08-27 KUICS34
- 35. 해시 충돌 (Hash Collision) • 한 반에 30명이 있을 때, 이 중 생일이 겹치는 사람이 있을 확률? • 기본적인 확률보다 낮은 경우의 수로 해시 충돌을 일 으키는 방법을 찾으면? 2015-08-27 KUICS35
- 37. 공인인증서 구조 어서 와 PKCS#8은 처음이지? 밤샘과 삽질의 시작 2015-08-27 KUICS37
- 38. 공인인증서 구조 • ‘공개키’ + ‘암호화된 개인키’ 구조 • 공개키 : signCert.der • 개인키 : signPri.key • Windows XP • C:Program FilesNPKI • Windows Vista 이후 • C:Users[계정명]AppDataLocalLowNPKI 2015-08-27 KUICS38
- 40. 공인인증서 구조 • 공개키 • X.509 규격 v3, Binary DER 인코딩 • 개인키 • Encrypted PKCS#8 포맷, Binary DER 인코딩 • 우리가 공략할 곳은 개인키 2015-08-27 KUICS40
- 41. 공인인증서 구조 - 개인키 • 암호화된 개인키는 크게 세가지 정보를 담고 있다. • 1) Salt • 2) Iteration • 3) Encrypted Private Key • 우리가 공략할 부분은 3번이며, SEED 128 CBC 로 암호화되어 있다. 2015-08-27 KUICS41
- 42. 공인인증서 구조 - 전자서명 과정 • 1. ActiveX를 설치한다. • 2. 비밀번호를 입력 받는다. • 3. PBKDF1, SHA1을 이용해 IV와 Key를 얻는다. • 4. Encrypted Private Key를 해독해서 개인키를 얻는 다. • 5. 개인키로 결제정보를 전자서명한다. • 6. {결제정보/전자서명/공인인증서의 공개키}를 결제 서버로 전송한다. • 7. 결제서버에서 사용자 공인인증서의 공개키로 전 자서명을 검증한다. 2015-08-27 KUICS42
- 43. 암호문 공격기법 끝나지 않는 창과 방패의 싸움 2015-08-27 KUICS43
- 44. 창과 방패 1 : 도청 vs 암호문 섞기 • 대칭키의 경우, 정보를 암호화해 안전하게 전달할 수 는 있지만 정작 그 키를 안전하게 전달할 수 없다. • 통신을 도청하다가 키를 습득하면 전 암호문 해독 가 능 2015-08-27 KUICS44 A B 대칭키 : !NC0GNI4O2015 C 이 키는 이제 제 겁니다. 제 마음대로 할 수 있는 것이 죠.
- 45. 창과 방패 1 : 도청 vs 암호문 섞기 • 이를 보완하기 위해 대칭키와 공개키 섞어 사용 • 사용할 대칭키를 공개키 암호를 사용해 전송 2015-08-27 KUICS45 A B A 공개키 B 공개키 A B (B 공개키로 암호화) 대칭키 전 송 (대칭키로 암호화) KUICS장하진
- 46. 창과 방패 1 : 도청 vs 암호문 섞기 • MITM 공격 (중간자 공격, Man in the Middle) • 정상 • 공격시 2015-08-27 KUICS46 A B A 공개키 B 공개 키 C 공개키 B 공개키 A B A 공개키 C 공개키 C
- 47. 창과 방패 1 : 도청 vs 암호문 섞기 • MITM 공격 (중간자 공격, Man in the Middle) 2015-08-27 KUICS47 A B A 공개키 C 공개키 C 공개키 B 공개키 C A B 장하진이 발표한다 장하진이 발표한다 C (도청중)
- 48. 창과 방패 2 : 브루트포싱 • 암호문에서 평문을 알아내고 싶다면? • 암호문에 쓰인 비밀번호가 가질 수 있는 모든 경우의 수를 일일이 대입한다 (Bruteforce) • 사용된 비밀번호의 복잡도에 비례하여 경우의 수가 매우 크게 증가한다. 설마 일일이 넣어볼 까? 그런데 그것이 실제로 일어났습니 다 2015-08-27 KUICS48
- 49. 흔한_해킹당하는_시나리오_1 • 1. A카드사가 털림 • 2. 비밀번호, 주민등록번호의 Hash 값 유출 • 3. (A카드사 曰 “비밀번호와 주민등록번호는 암호화 되었으므로 안전합니다”) • 4. 해커는 Hash에서 원래의 값을 알아내려 하지만, 너무 오래 걸려 FAIL • 5. 개인정보는 안전하게 보호 2015-08-27 KUICS49
- 50. 창과 방패 3 : 사전 공격 • 모든 경우의 수를 다 넣어보자니 시간이 너무 오래 걸린다. • 사람들이 쓸만한 비밀번호를 추려서 넣어보자! • 추려놓은 목록을 ‘Dictionary’라고 지칭 • 허접한(...) 비밀번호를 쓰는 사람들에게 효과적 2015-08-27 KUICS50
- 51. 창과 방패 4 : Rainbow Table • 공개키 암호, 해시함수 를 매우 빠르게 뚫을 수 있는 궁극의 병기 • 용량이 매우 크다 • 제작을 할 때 굉장히 긴 시간과 큰 용량 필요 • 완성되기만 하면 그 해 시함수는 무력화된다. 2015-08-27 KUICS51
- 52. 흔한_해킹당하는_시나리오_2 • 1. B카드사가 털림 • 2. 비밀번호, 주민등록번호의 Hash 값 유출 • 3. (B카드사 曰 “비밀번호와 주민등록번호는 암호화 되었으므로 안전합니다”) • 4. 해커는 Rainbow Table을 활용해 비밀번호와 주민 등록번호를 알아낸다 • 5. 보안체계 무력화 • 6. 개인정보 == 공공재 2015-08-27 KUICS52
- 53. 창과 방패 5 : Salt • 한 해시함수에 대한 레인보우 테이블의 완성은 그 해 시함수의 무력화를 의미 • 하지만, 비밀번호의 길이를 인위적으로 늘려버린다 면? • 사람들이 짧은 비밀번호를 입력해도, 임의의 문자열 을 덧붙인 뒤 해싱하여 경우의 수를 크게 늘린다. 2015-08-27 KUICS53 SHA256(password + WjW9s34kdXSLic1) SHA256(password) vs
- 54. 흔한_해킹당하는_시나리오_3 • 1. 포털 C가 털림 • 2. 비밀번호의 Hash 값 유출 • 3. 해커는 Rainbow Table을 활용해 비밀번호 해독 시도 • 4. Salt 때문에 경우의 수가 기하급수적으로 증가한 상태라 이를 커버하는 Rainbow Table을 구할 수 없 다 • 5. 시간을 벌고, 그 사이 전 회원의 비밀번호를 변경 해 방어 성공 2015-08-27 KUICS54
- 55. 창과 방패 6 : 뱅뱅이 (Iteration) • 한 번 해싱하는 걸로는 부족하다! 여러 번 돌려버리 자! • 뱅뱅이 돌린만큼 브루트포싱할 때 오래 걸린다. • Ex) Linux • SHA512(SHA512(…(SHA512(password+salt)…)); 2015-08-27 KUICS55 ↑ 총 5000번!
- 56. 창 업그레이드 1 : 멀티쓰레딩 • 현대의 CPU는 여러 개의 코어를 가지고 있다. • 시험 답안지 100명분을 1명이 채점하는 것보다 4명 이 채점하는 것이 4배 빠르다. • 동원할 수 있는 CPU의 자원을 모두 동원하자! 2015-08-27 KUICS56
- 57. 창 업그레이드 1 : 멀티쓰레딩 • 일손은 많은데 놀고 있으면 아깝잖아요 2015-08-27 KUICS57
- 58. 창 업그레이드 1 : 멀티쓰레딩 • 이 아름다운 CPU 100%를 보라! 2015-08-27 KUICS58
- 59. 창 업그레이드 1 : 멀티쓰레딩 • 여러 개의 코어를 동시에 사용하려면 쓰레드를 사용 한다. • 운영체제마다 쓰레드를 사용하는 방법이 다 다르며, 그나마도 복잡하다. • 병렬프로그래밍은 일반 프로그래밍보다 고려할 것 이 많다. • OpenMP – 모든 운영체제에서 사용할 수 있는 범용 병렬프로그래밍 라이브러리, 쉽다! 2015-08-27 KUICS59
- 60. 창 업그레이드 2 : GPGPU • CPU는 복잡한 연산을 뚝딱뚝딱 처리하는 엘리트이 지만, 코어 수가 적고 비싸다. • GPU는 간단한 연산에만 특화되어 있는 막노동꾼이 지만, 코어 수가 굉장히 많고 싼 편이다. • 각각의 능력이 낮은 편이어도 인해전술로 처리한다. • -> 병렬화에 매우 유리! 2015-08-27 KUICS60
- 61. 창 업그레이드 2 : GPGPU • CPU는 죽어라 일하는데 GPU 너는 놀겠다고? 2015-08-27 KUICS61
- 62. 창 업그레이드 2 : GPGPU • GPU의 병렬전술! 효과는 대단했다! 2015-08-27 KUICS62
- 63. 창 업그레이드 2 : GPGPU • GPGPU? • 그래픽 연산만 하는 GPU에게 우리가 원하는 연산을 시키기 위한 방법 • CUDA : NVidia 그래픽카드 전용, 쉽다. • OpenCL : 모든 그래픽카드에서 쓸 수 있다, 어렵다. 2015-08-27 KUICS63
- 64. 공인인증서 크래킹 Bruteforcing : 갈림의 시작 2015-08-27 KUICS64
- 65. 1단계 : 공인인증서 구조 분석 • 브루트포싱을 위해 개인키를 복호화하는 과정과 전 자서명을 위해 개인키를 복호화하는 과정은 동일하 다. • Salt, Iteration, Decrypted Data를 어떻게 처리해서 개인키를 얻을 수 있을지 궁리해야 했다. • 국내에서만 쓰이는 공인인증서 특징상, 자료가 거의 없어 생고생 2015-08-27 KUICS65
- 66. 2단계 : 개인키 파일 파싱 • Binary DER Encoding • Encrypted PKCS#8 구조 • DER 포맷을 파싱해 세가지 정보를 추려낸다. • Salt • Iteration • Encrypted Private Key 2015-08-27 KUICS66
- 67. 2단계 : 개인키 파일 파싱 • Hex Editor로 뜯어보면 다음과 같이 나뉩니다. 2015-08-27 KUICS67 Binary DER, Length
- 68. 2단계 : 개인키 파일 파싱 • 구조를 알아냈으면 코딩을 해야겠죠. 2015-08-27 KUICS68 NPKIPrivateKey 구조체에 NPK_Parse 함수를 이용해 서 정보를 담습니다.
- 69. 3단계 : IV, Key 계산 ? 2015-08-27 KUICS69
- 70. 3단계 : IV, Key 계산 ?? 2015-08-27 KUICS70
- 71. 3단계 : IV, Key 계산 무슨 소리인고? 2015-08-27 KUICS71
- 72. 3단계 : IV, Key 계산 • SHA1 : 해시 함수 • PBKDF1 : SHA1를 뱅뱅이 돌리는 해시 함수 • 1) 비밀번호에 Salt 붙여서 그걸 PBKDF1에 Iteration Count만큼 뱅뱅이 돌려라! • 2) 20바이트 결과물 중 처음 16바이트를 Key로 사용 • 3) 나머지 4바이트를 SHA1 해시해서 처음 16바이트 를 IV로 사용 2015-08-27 KUICS72
- 73. 3단계 : IV, Key 계산 백문이 불여일견 2015-08-27 KUICS73
- 74. 3단계 : IV, Key 계산 2015-08-27 KUICS74 Password PBKDF1 PBKDF1 PBKDF1 PBKDF1 Returned 20Byte 16Byte 4Byte Salt strcat(Password, Salt) PBKDF1 SHA1 Returned 20Byte 16Byte 4Byte
- 75. 3단계 : IV, Key 계산 C로 코딩하면 2015-08-27 KUICS75
- 76. 4단계 : SEED 복호화 2015-08-27 KUICS76 PBKDF1 PBKDF1 PBKDF1 SEED_CBC128_Decrypt Decrypted Data Key IV PBKDF1 IsPaddingOK PBKDF1 SEED_RoundKey Encrypted Data
- 77. 4단계 : SEED 복호화 C로 코딩하면 2015-08-27 KUICS77
- 78. 5단계 : 나올 때까지 무한반복 2015-08-27 KUICS78 PBKDF1 PBKDF1 PBKDF1 NPKI_Decrypt Decrypted Data N’th Password PBKDF1 IsPaddingOK PBKDF1 BruteForceIterate
- 79. 5단계 : 무한반복 • BruteForceIterate() • 새 비밀번호를 생성하고, 이 비밀번호가 맞는지 검사 • 맞는 비밀번호가 나올 때까지 무한반복 • NPKI_Decrypt() • 주어진 비밀번호로 이 공인인증서를 복호화 시도 • 속도는? • Intel Core i7-4770 기준 6800개/초 비밀번호 대입 가 능 • GPGPU 사용시 속도를 더 획기적으로 끌어올릴 수 있다. 2015-08-27 KUICS79
- 80. 이론 속의 멀티쓰레딩 2015-08-27 KUICS80
- 81. 실전 속의 멀티쓰레딩 2015-08-27 KUICS81
- 82. CPU를 갈아 비밀번호를 얻어봅시다 2015-08-27 KUICS82
- 83. CPU를 갈아 비밀번호를 얻어봅시다 2015-08-27 KUICS83
- 84. CPU를 갈아 비밀번호를 얻어봅시다 2015-08-27 KUICS84
- 85. CPU를 갈아 비밀번호를 얻어봅시다 2015-08-27 KUICS85
- 86. CPU를 갈아 비밀번호를 얻어봅시다 2015-08-27 KUICS86
- 87. CPU를 갈아 비밀번호를 얻어봅시다 2015-08-27 KUICS87
- 88. CPU를 갈아 비밀번호를 얻어봅시다 2015-08-27 KUICS88
- 89. GPU를 갈아 비밀번호를 얻어봅시다. • CPU에서 OpenMP까지는 적용하는데 성공 • GPGPU를 위해 OpenCL로 포팅하는 것은 안정성 부족으로 실패 • 시간만 좀 더 있었더라면 초당 수백만번씩 뽑아내는 OpenCL 크래커를 만들 수 있었을 텐데, 아쉽습니다. • 준혁형의 컴퓨터가 이거 돌리다가 하루에 20번씩 꺼 진 적이… 2015-08-27 KUICS89
- 90. 오늘의 교훈 초간단 요약 2015-08-27 KUICS90
- 91. 오늘의 교훈 : 초간단 요약 To 사용자 • 공인인증서 비밀번호는 길게 길게 만들자 • 공인인증서 비밀번호에 특수문자를 듬뿍듬뿍 넣자 • 할 수 있다면, 공인인증서 비번을 주기적으로 바꾸자 To 크래커 • Rainbow Table을 구축, 저장할 수 있는 공간을 확보 • GTX980 Ti 같은 걸 사서 GPGPU로 BruteForcing ㄱ ㄱ • (아, 정신건강을 위해 OpenCL 말고 CUDA 쓰세요) 2015-08-27 KUICS91
- 92. Reference • ECB, CBC (Encryption, Decryption) • https://en.wikipedia.org/wiki/Block_cipher_mode_of_oper ation • Tux Image (ECB, CBC) • Larry Ewing (lewing@isc.tamu.edu),The GIMP • SEED – 암호 알고리즘 규격[v1.21] • https://seed.kisa.or.kr/iwt/ko/sup/EgovSeedInfo.do • http://www.rootca.or.kr/kor/standard/standard01B.jsp 2015-08-27 KUICS92
- 93. Source Code • ied206/NPKICraker on Github • Licensed under MIT License • https://github.com/ied206/NPKICracker 2015-08-27 KUICS93
- 94. Q & A 2015-08-27 KUICS94
Notas del editor
- 안녕하십니까, ‘공인인증서 크래킹’에 대해 발표할 장하진입니다.
- 저는 고려대학교 컴퓨터학과 2학년으로 재학 중이고, KUICS의 제 12대 회장입니다. 이번 여름방학부터는 Best of the Best 4기 교육생 생활을 하고 있습니다.
- GPGPU와 OpenCL 쪽을 맡아주신 KUICS의 이준혁씨에게 감사하다는 말로 시작하겠습니다.
- 목차는 다음과 같습니다. 먼저 현대암호의 종류와 각각의 특징에 대해 알아본 뒤, 이것들이 공인인증서에 어떻게 적용되어 있는지 살펴보고, 이러한 암호문을 어떻게 크래킹할지 살펴보는 순서입니다.
- 현대암호 이전의 암호는 암호문에서 원문을 유추하는 것이 가능했습니다. 하지만 현대암호는 불가능합니다. (클릭 – 오른쪽을 가리키며) 현대암호에서는 원문의 특징이 아예 사라져 버립니다. (클릭) 왜냐하면 현대암호는 수학적 원리에 기반하기 때문입니다.
- 양방향 암호화는, 암호문을 다시 평문으로 복호화 가능한 암호입니다. 단방향 암호화는, 암호문을 평문으로 되돌릴 수 없는 비가역적 암호화입니다. Encryption이란 용어는 양방향을 의미하고, Hashing이란 용어가 단방향을 의미한다고 생각하시면 되겠습니다.
- 양방향 암호는 크게 두 가지로 분류됩니다. 대칭키와 공개키입니다. (클릭) 대칭키는 대칭암호, 공개키는 비대칭암호에 해당합니다. (화면 가리킴) 대표적인 알고리즘으로는, (클릭) 대칭키에 AES, (클릭) 공개키에 RSA가 있습니다.
- 대칭키 암호는 암호화할 때 사용하는 키와 복호화할 때 사용하는 키가 같습니다. 흔히 ‘암호’라고 하면 떠오르는 그 암호입니다. 연산속도가 빠른 편에 속하기 때문에 자주 쓰이죠. 이 암호는 다시 스트림 암호와 블록 암호로 나뉘어집니다. 이 중, 블록 암호가 공인인증서에 쓰입니다.
- 스트림 암호에서 스트림은 정수필터를 생각하시면 됩니다. 정수기에 수도관을 연결하고, 물, 즉 정보를 하나씩 흘려보낼 때마다 필터를 통과하며 성질이 바뀌겠죠. 물은 연속적이듯이 스트림도 연속적입니다. 따라서 스트림 암호에는 정해진 길이가 없습니다. 뒤에서 설명할 블록 암호보다 일반적으로 빠른 편이지만, 보안성은 낮은 편입니다. 주로 네트워크 암호화에 쓰입니다. 대표적으로 RC4가 존재합니다.
- 블록 암호는 특정 길이를 가진 입력에 대해서만 암호화를 시킬 수 있습니다. 일반적으로 스트림 암호보다 느린 편이지만, 보안성은 더 높습니다. 실생활에서 가장 대중적으로 쓰이는 암호방식입니다. 대표적으로 미국에서 만들어진 DES, AES와 한국에서 만들어진 SEED, ARIA가 존재합니다.
- 한국에서 만들어진 대칭키 블록 암호입니다. 1990년대 후반 당시, 미국에서 최신 기술이었던 128비트 암호를 수출규제하고 있었기에 최신 암호를 쓰기 위해선 직접 만드는 방법밖에 없었습니다. 이후, SEED는 국내 암호 표준이 되었고 지금도 국내에서 자주 사용합니다. (국내에서만 써서 문제죠) 몇 년뒤 국정원에서 ARIA라는 암호를 개발하였고, 역시 국내에서 자주 쓰고 있습니다.
- 블록 암호의 경우, 정해진 길이의 입력만 받을 수 있습니다. 그런데 암호화해야 할 메시지의 길이는 전부 다 제각각입니다. 그래서, 메시지의 길이를 블록길이의 배수로 맞춰줘야 합니다. 그것을 ‘패딩’이라고 부릅니다.
- (각 종류 설명) PCKS#7이 주로 쓰이며, PCKS#5라고도 불립니다.
- 블록 암호에서 암호화를 할 때, 각각의 블록들끼리는 어떤 관계를 가지게 될까요? 이것을 결정하는 것이 암호화 모드입니다. ECB, CBC 등이 자주 쓰이죠. 자, 그런데 왜 굳이 복잡하게 여러 개를 만들었을까요?
- 각각의 블록이 독립적으로 암호화되며, 구조가 가장 단순합니다. 암호화 복호화 모두 병렬화가 가능합니다. 그러면 이걸 쓰면 되지 왜 다른 것을 만들었을까요?
- 각각의 블록이 독립적으로 암호화되며, 구조가 가장 단순합니다. 암호화 복호화 모두 병렬화가 가능합니다. 그러면 이걸 쓰면 되지 왜 다른 것을 만들었을까요?
- 자, 이 사진을 보실까요? 오른쪽 사진은 암호화된 파일입니다. 그런데 얘가 어떤 포켓몬인지 다 보이네요. 뭐죠? (치코리타) (인코그니토 회장님 조현규씨께서 이 사진에 대한 재미있는 기억을 가지고 계시죠) (클릭) 여기서 볼 수 있듯, ECB는 같은 입력이 들어가면 반드시 같은 결과가 나옵니다. 그래서, 암호문에서 각각의 블록 사이의 관계를 유추할 수 있습니다. 이러면 안 되겠죠.
- Chaining이라는 이름에서 볼 수 있듯, 직전 블록의 암호문이 다음 블록을 암호화할 때 쓰입니다. 그렇게 되면 같은 블록이 들어와도, 직전 블록이 완벽하게 똑같기는 힘드니 더욱 안전해집니다. 그러면 최초의 블록은 어떻게 처리할까요? 초기화 벡터 (IV)를 붙여서 계산합니다. 대부분 IV는 비밀번호에서 계산하는 경우가 많습니다.
- CBC의 특징은, 암호화할 때는 직전 블록이 암호화되기를 기다려야 하므로 병렬처리를 할 수 없습니다. 하지만 복호화할 때는 암호화된 직전 블록을 읽어오기만 하면 되므로 병렬처리가 가능합니다.
- ECB가 이거라면, CBC는 이런 결과가 나옵니다. 암호문에서 각각의 블록 사이의 관계를 유추할 수 없는 겁니다. 그래서 CBC가 가장 대중적으로 쓰이는 암호화 모드이며, 공인인증서도 CBC 모드를 사용합니다. 나머지 모드들은 잘 안 쓰여요.
- 비대칭키 암호는 암호화할 때 사용하는 키와 복호화할 때 사용하는 키가 다릅니다. 키를 주고받을 필요가 없기에 안전하지만, 속도가 비교적 느리고 암호문이 길어집니다. 개인키와 공개키가 쌍으로 존재하며, A-B가 쌍이면 A로 암호화하면 B로밖에 풀 수 없고, B로 암호화하면 A로만 풀 수 있습니다. 이러한 점에서 공개키 암호라고도 불립니다. 공인인증서의 주 기능인 전자서명, 부인방지는 바로 이 비대칭키 암호의 원리에 기반합니다. 대표적으로 RSA, ECC (타원 암호) 등이 있습니다.
- 개인키와 공개키를 쌍으로 생성한 뒤, 개인키는 안전하게 본인만이 가지고 있고, 공개키만 외부로 공개합니다. 이러한 특징 때문에 공개키 개인키라는 이름이 붙었죠. 서로의 공개키를 교환하고, 상대방의 공개키로 정보를 암호화해서 보내면 오직 상대방만이 이를 열어볼 수 있습니다. 언제나 도청당할 수 있는 인터넷에서 자료를 안전하게 주고받을 수 있는 암호체계죠.
- 자신의 개인키로 특정 정보를 암호화해서 공개하면 제 공개키로만 암호가 풀리겠죠. 그래서 “내가 이 정보에 서명했다”라는 것을 입증할 수 있습니다. 이는 전자서명의 이론적 토대가 되며, 공인인증서의 전자서명/부인방지 특성은 여기에서 나옵니다.
- 그러면 모든 정보를 비대칭키로 통신하면 되지 않을까요? 하지만, 대칭키 암호에 비해 비대칭키 암호는 매우 복잡하고, 속도가 느립니다. 그래서, 대칭키 암호와 비대칭키 암호는 상호 보완적으로 쓰입니다. SSL 같은 암호화 통신에서는 대칭키 암호에 사용할 키를 공개키 암호를 이용해 안전하게 주고받은 후, 대칭키 암호로 통신합니다.
- 가장 널리 쓰이는 알고리즘이며, 매우 큰 두 소수를 이용해서 키 쌍을 생성합니다. RSA를 깨려면 매우 큰 연산량이 필요한데, 이는 현실적인 시간 안에 뚫기 어려운 수준입니다. 1990년대 후반에 발표되었지만 지금까지도 약방의 감초로 쓰이고 있습니다.
- 공인인증서의 기본 원리지만, 크래킹할때는 연관이 없습니다. +인증서 사진
- 단방향 암호화란, 한번 암호화하면 평문으로 되돌릴 수 없는 암호기법을 말합니다. Hash 함수가 여기 해당합니다. (클릭) 해시함수는 ‘임의의 길이’를 가진 문자열을 입력 받아 ‘고정된 길이’의 해시값을 출력하는 함수입니다. 또한, 역함수가 존재하지 않아 해시에서 원래의 문자열을 복구할 수 없습니다. 이러한 특징 덕분에 특정 정보의 해시값은 특정 정보의 ‘지문’처럼 쓰입니다.
- 역사적으로 많은 Hash 함수가 개발되었으며, 왼쪽부터 먼저 개발되었고 오른쪽으로 갈수록 강력합니다. 시간이 지날수록 옛날 해시에 대한 공격이 쉬워지기 때문에, 최대한 최신의 Hash를 이용하는 것은 필수입니다. (클릭 - 그림을 가리키며) Hash 함수에 집어넣는 값이 일부만 바뀌어도 매우 다른 결과가 나오는 것을 볼 수 있습니다. 이를 눈사태 효과라고 합니다. 그런데 서로 다른 문자열을 입력했는데 같은 해시가 나오는 게 가능할까요? 비둘기집의 원리에 따라 반드시 존재합니다. 해싱가능한 문자열의 길이는 제한이 없지만 나올 수 있는 해시의 경우의 수는 제한되어 있기 때문입니다. 암호학에서는 계산적으로 충돌을 찾아내는 것이 사실상 불가능한 함수를 강한 충돌 저항성을 가진다고 표현합니다. 지금 널리 쓰이는 해시함수들도 개발될 당시, 강한 충돌 저항성을 가졌다고 인정되었기에 널리 사용되고 있습니다.
- HelloHash라는 문자열을 암호화해 보겠습니다. (클릭 x 2) 이 두 문자열에서 원본을 유추하기는 불가능에 가깝습니다.
- 해시함수는 다양한 곳에 쓰이고 있습니다. 웹서비스에서 회원을 관리할 때, 데이터베이스에 비밀번호를 그대로 저장하는 것은 해커의 칩입에 매우 위험합니다. 비밀번호를 저장할 때 양방향 암호화를 이용할 수 있지만, 암호화에 사용했던 키를 탈취당할 수 있다는 문제가 있습니다. 반면, 회원이 로그인할 때 서버가 필요한 정보는 ‘너가 가입할 때 넣었던 비밀번호랑 일치하다’ 뿐입니다. 이 일치의 대상을 ‘비밀번호의 지문’으로 바꿔도 식은 그대로 성립하죠. 따라서, 비밀번호의 지문인 해시만을 DB에 저장하고 서버에서는 해시끼리만 비교한다면 안전하게 비밀번호를 DB에 저장할 수 있습니다. 해커가 DB를 탈취해도 해시에서 원래 비밀번호를 복구할 수는 없기에 비밀번호는 이론상 안전합니다. 또한, 흑심을 품은 서버관리자가 비밀번호를 알아낼 수도 없습니다. (클릭) 이 사진은 예전 퀵스 홈페이지의 DB입니다. 제가 여러분에게 DB 덤프를 그대로 보여줘도 비밀번호 자체는 안전하죠. 해시가 활용되는 다른 분야는 파일의 무결성 검사가 있습니다. 인터넷망의 품질이 좋은 우리나라에서는 흔치 않지만, 인터넷망이 불안정한 해외의 경우 파일을 다운받다가 깨지는 경우가 종종 발생합니다. 파일의 무결성은 어떻게 감지할까요? (클릭) 홈페이지에서 제공하는 해시값을 본 뒤, 동일 알고리즘으로 다운로드받은 파일의 해시값이 이와 일치하는지 보면 됩니다. 이는 해시를 입력의 ‘지문’처럼 쓸 수 있는 것에서 착안되었습니다. 입력의 1bit만 바뀌어도 눈사태 효과로 인해 해시는 크게 바뀌기 때문에, 사람의 지문처럼 파일이 가질 수 있는 고유한 값이 되는 것입니다. 또한, 전자서명의 효율성을 위해서도 해시가 쓰입니다. 우리가 자주 접하는 공인인증서가 전자서명입니다. 전자서명은 공개키 암호화를 쓰기 때문에, 연산량이 많습니다. 그래서 한 문서에 대해 전자서명을 해야 할 때, 문서 전체에 대한 서명, 즉 공개키 연산을 하는 것은 오래 걸립니다. 그렇다면, 그 특정 문서의 고유값인 해시에 대해서만 공개키 연산을 한다면 같은 효과를 내면서 더 빠르게 처리할 수 있겠죠. 해시값에 대한 서명이 원 메시지에 대한 서명으로 인증되기 위해선 같은 해시값을 가지는 다른 메시지가 존재할 확률이 매우 낮아야 합니다. 그래야 고유한 문서에 대한 서명으로 인정될 수 있기 때문입니다. 따라서, 해시함수는 충돌이 일어날 수밖에 없는 구조이지만 충돌이 일어날 확률을 최대한 낮춰야 합니다.
- 해시 충돌이 자주 발생하면 해시를 더 이상 무결성 검사와 전자서명에 사용할 수 없게 됩니다. 역으로 생각하면 해시 충돌을 발견하면 이를 해킹에 충분히 활용할 수 있다는 뜻입니다. 이 문제의 답을 아시는 분? (침묵) 무려 70%입니다. 이 원리를 이용하면 만들어질 수 있는 모든 해시를 계산해보지 않아도 계산적으로 충돌을 찾을 수 있습니다. (클릭) 이 표를 보면, 128bit 해시는 10의 38승의 경우의 수를 가지지만, 이 경우의 수에 제곱근을 씌운 수인 10의 19승번 동안만 해시를 계산해보면 충돌 확률을 75%에 가까이 올릴 수 있습니다. 한 해시 함수에 대해 이 표에 적힌 경우의 수보다 빠른 충돌 공격이 발견되면 그 함수는 ‘broken’이라고 표현합니다. MD5는 상당히 전에 깨졌으며, SHA1도 몇 년 전에 깨졌습니다.
- sha256이 서명 알고리즘에 쓰이고, 이 공개키 자체의 지문은 sha1으로 기록되어 있네요.
- 공인인증서는 공개키와 암호화된 개인키의 쌍으로 이루어져 있습니다, (클릭) 다음과 같은 이름과 (클릭) 폴더에 저장되어 있지요. 아, 맥이나 리눅스요? 뭘 기대합니까 으허항하 비밀번호 브루트포싱은 개인키만 있으면 가능하다.
- 왼쪽은 공개키, 오른쪽은 개인키 파일입니다. 30 82 로 시작한다는 것을 잘 봐두세요.
- 공개키는 X.509 표준의 버전 3으로 구성되어 있고, Binary DER로 인코딩되어 있습니다. 개인키는 Encrypted PKCS#8 포맷을 따르고 있고, 역시 Binary DER로 인코딩되어 있습니다. 우리가 공략할 곳은 개인키입니다. 비밀번호 브루트포싱은 개인키만 있으면 가능하거든요. 공개키는 전자서명에 필요하지만, 거기까지는 오늘 다루지 않습니다.
- 암호화된 개인키는 크게 세가지 정보를 담고 있습니다. Salt, Iteration, Encrypted Private Key. 앞 두가지는 뒤에서 설명할테니 이름만 봐두시고, 지금은 3번 부분에 진짜 개인키가 SEED 128비트 CBC 모드로 암호화되어 있다는 것만 알아두시면 됩니다.
- 우리 눈에는 1, 2번만 보이죠. 하지만 내부적으로는 많은 작업이 일어납니다. 우리가 입력한 비밀번호를 적절히 가공해서 IV, Key를 만들어낸 뒤, 전자서명을 하고 그걸 서버에 전송합니다. 이 부분이 중요한 이유는, 1번부터 4번까지는 공인인증서 크래킹에도 필수적인 부분이기 때문입니다.
- 이 방법은 통신이 이루어지는 실시간에 도청하는 방법입니다. 앞에서 대칭키의 경우 정보를 암호화해서 안전하게 전달할 수는 있지만, 정작 그 키를 안전하게 주고받을 방법이 없다고 했었죠. 통신을 미리 도청하고 있다가 대칭키를 주고받는 순간 낚아채버리면 끝입니다.
- 그래서 대칭키를 주고받는 그 순간에는 공개키를 쓰면, 성능도 크게 떨어뜨리지 않고 안전하게 통신할 수 있게 되죠. 이것이 SSL이 쓰는 방식입니다.
- 그렇지만, 공격자가 통신의 중간에 아예 끼어들어서 A에게는 B인척, B에게는 A인척 한다면 A와 B는 속도 모든 키와 통신내용을 보여주게 되겠죠. 이걸 막기 위해서 SSL에 인증서가 도입되었습니다. “내가 정말 B다!” “어 그래? 경찰이 너가 정말 B이라고 인정한 인증서를 내놔!”
- 이건 통신이 이루어질 당시에만 가능
- 방금까지는 암호화 통신이 이루어질 바로 그 때 도청하는 방법이었죠. 이제부터는 이미 암호화된 것을 뚫는 방법들을 소개합니다. (클릭) 암호문의 비밀번호를 알아내거나 해시의 원문을 찾아내는 것은 이론상 불가능하지만, 방법이 아예 없는 건 아닙니다. (클릭) 사물함 자물쇠를 딸 때, 000부터 999까지 넣어보는 방법이 가장 간단합니다. 이는 현대암호에도 마찬가지입니다. (클릭) 하지만 이는 시간이 오래 걸립니다. (클릭) 아무리 컴퓨터가 노가다에 특화되어 있다고는 하지만, 컴퓨터를 동원해도 오래 걸리긴 마찬가지입니다.
- 해시암호가 비밀번호 암호화에 쓰이니 해시를 예로 들어보죠. (클릭) 한 카드사가 해킹당한 상황을 가정해 보겠습니다. (클릭) 다행히 암호화되어 있습니다. (클릭) 뉴스에서 질리도록 들은 멘트가 나오고, (클릭) 해커는 암호를 풀지 못합니다. (클릭)
- 컴퓨터로도 처리하는데 시간이 꽤 걸리는 노가다 작업이 암호문 브루트포싱입니다. (클릭) 그래서 많은 사람들이 쓸 만한 비밀번호를 추려서 그것만 넣어보는 시도가 생겼습니다. 어차피 오래 걸려서 다 못 넣어보니 확률 높은 거라도 넣어보자는 의미입니다. (클릭) 그 추려놓은 목록을 DIctionary라고 부릅니다. (클릭) 1q2w3e4r, password과 같은 허접한 비밀번호를 쓰는 사람들과, 간단한 단어를 조합해 쓰는 사람들에게 효과적입니다.
- 사전 공격도 오래 걸리기는 매한가지라, 크래커들은 컨닝페이퍼를 만들어버렸습니다. (클릭) 레인보우 테이블은 암호문 크래킹에 있어 궁극의 병기입니다. 다만 용량이 꽤(?) 큽니다. (클릭) 100개의 문제가 있는 시험지를 채점한다고 합시다. 조교A는 일일이 문제를 풀어보면서 채점합니다. 당연히 시간이 오래 걸립니다. 하지만 조교B는 다른 사람이 만들어 둔 해답지를 가져와 비교합니다. 순식간에 채점이 끝났습니다. 이 때, 레인보우 테이블은 해답지와 같은 존재입니다. (클릭) 어차피 해답지를 만들려면 최소 한 번은 문제를 풀어봐야 합니다. 하지만 일단 레인보우 테이블이 완성되면, 그 해시 함수는 무력화됩니다. (클릭 – 2TB를 가리키며) 이 정도의 용량을 자랑합니다. 다행으로, 모든 경우의 수를 커버하는 레인보우 테이블을 제작하는 것은 매우 긴 시간이 걸리고, 그것을 담을 수 있는 하드디스크도 존재하지 않을 정도로 용량이 매우 커집니다. 따라서 간단한 패턴에 대해서만 레인보우 테이블이 생성되어 있습니다. 그래서 비밀번호에 특수문자를 넣고, 길게 만들면 레인보우 테이블의 사정권에서 어느 정도 벗어날 수 있습니다.
- (클릭) 아까 열 받은 해커가 다른 카드사를 털었습니다. (클릭) 이번에도 암호화되어 있습니다. (클릭) 뉴스에서 질리도록 들은 멘트가 또 나오지만 (클릭) 해커는 레인보우 테이블을 활용해 암호를 풀어버립니다. (클릭)(클릭) 그리고 우리 개인정보는 공공재가 됩니다.
- 이제는 보안담당자가 열 받았습니다. 어떻게 외양간을 고쳐야 할까요? (클릭) 비밀번호에 대한 해시함수의 레인보우 테이블은 용량과 제작시간 때문에 20자리를 넘는 경우가 거의 없습니다. (클릭) 따라서 비밀번호에 임의의 문자열을 덧붙여 길이를 인위적으로 늘린 뒤 해싱하면 레인보우 테이블의 사정권에서 확실하게 벗어날 수 있습니다. (클릭) 또한, 사용자가 거지같은 비밀번호를 사용해도 사전 공격으로부터 보호할 수 있습니다. (클릭) 이렇게요. (클릭) 새로운 회원이 가입할 때마다 임의의 SALT를 생성해 DB에 집어넣는 방식입니다. 비밀번호의 길이가 늘어나는 효과를 주기 때문에 레인보우 테이블 방어에 효과적이죠.
- (클릭) (클릭) 이번에는 전과 달리 마냥 당하지 않습니다. (클릭) Rainbow Table을 동원해도 salt 기법을 통해 쉽게 뚫지 못하게 막았으니까요. (클릭) 해커는 이를 뚫는데 상당한 시간을 투자해야 할 거고 (클릭) 그 사이에 비밀번호를 변경해버리면 기껏 해킹한 것이 무용지물이 됩니다.
- 역시 해시함수에 해당하는 건입니다. 한 번 해싱하는 걸로는 부족하니, 아예 여러번 돌려버리는 방법입니다. 로그인할 때 0.5초 느려지는 건 개인이 별로 못 느끼지만, 크래커 입장에서는 모든 경우의 수에 대해 0.5초씩 딜레이가 생기면 어마어마한 시간 지연이 됩니다. 실제로, 리눅스는 비밀번호를 저장할 때 Salt를 붙이고, 비교적 최신 해시함수인 SHA512를 5000번 돌려버립니다. 크래킹을 한번 시도해 봤더니 Salt, Iteration이 없는 윈도우에 비해 굉장한 시간 지연을 보여줬습니다. 윈도우에서 4글자는 1초만에 뚫리는데, 리눅스 4글자는 3분을 버텼습니다.
- 브루트포싱은 가장 확실하지만 느린 공격법인데, 어떻게 속도를 올릴까요? 현대의 CPU는 여러 개의 코어를 가지고 있지만, 우리가 짜는 프로그램은 대부분 1개 코어만을 사용하죠. 이 때, 놀고 있는 다른 코어도 데려다가 일을 시켜 버리는 겁니다. 당연히 코어가 4개면 4배만큼 빨라지겠죠.
- 한 프로세스에서 여러 코어를 동시에 사용하려면 쓰레드를 사용하면 됩니다. 하지만, 쓰레드는 운영체제마다 사용하는 방법이 다 다르고 복잡합니다. 또한, 다른 쓰레드가 동시에 같은 값을 쓰려고 시도하는 문제, 레이스 컨디션 등등 고려해야 할 것이 많죠. 하지만 OpenMP를 사용하면 이런 귀찮은 점을 적지 않게 해소할 수 있습니다. 이번 크래킹에서는 OpenMP를 활용하였습니다.
- CPU는 복잡하고 다양한 연산을 잘 처리하는 엘리트입니다. 하지만 엘리트이기에 비싸고 코어 수도 적죠. 반면, GPU는 간단한 연산만 잘 하는 막노동꾼이지만, 코어 수가 굉장히 많아 병렬로 인해전술하기 딱 좋습니다.
- CPU에 명령을 내리기 위해서는 C언어와 같은 프로그래밍 언어를 사용하듯이, 평상시 그래픽 계산만 하고 있는 GPU에 명령을 내리기 위해선 GPGPU를 사용해야 합니다. 크게 두가지 언어가 있는데, CUDA와 OpenCL입니다. 이번 크래킹에서는 OpenCL를 시도해 보았는데, 굉장히 어려운 편에 속합니다. (CPU에서의 상식이 전혀 먹히질 않습니다.) CUDA는 안정적인 반면 OpenCL에게 메모리 보호란 없습니다.
- 앞에서 전자서명하는 과정을 살펴본 이유는, 이 과정이 브루트포싱을 위해 개인키를 복호화하는 과정과 동일하기 때문입니다. 또한, 개인키에서 얻을 수 있는 자료를 어ᄄᅠᇂ게 처리해야 할지도 과제였습니다. 게다가 국내에서만 공인인증서가 쓰이는 특성상 자료가 거의 없어 많은 고생을 했습니다.
- 앞서 보았듯이, 개인키는 Binary DER 로 인코딩되어 있고 Encrypted PKCS#8 구조를 가지고 있습니다. 이 파일을 파싱해 세가지 정보를 추려냈습니다.
- 앞서 보았듯이, 개인키는 Binary DER 로 인코딩되어 있고 Encrypted PKCS#8 구조를 가지고 있습니다. 이 파일을 파싱해 세가지 정보를 추려냈습니다. Hex Editor로 뜯어보면 다음과 같은 위치에 위치하고 있음을 알 수 있죠. 맨 앞에 30 82가 있는 것도 DER 인코딩의 특징입니다.
- 이제 그걸 파싱하는 코드를 짰습니다.
- 이제 IV와 SEED 복호화에 직접적으로 쓰이는 Key를 계산해야 합니다. 그런데 이 문서... 뭘 어떻게 하라는 걸까요?
- 뭐 풀어쓰면 이런 뜻이긴 한데, 뭐가 뭔지 잘 모르겠네요.
- 그래서 준비했습니다.
- PBKDF1은 SHA1를 여러번 뱅뱅이 돌리는 함수로 생각하시면 됩니다. 이번에 사용한 금융결제원 공인인증서의 경우, Salt를 붙인 뒤 2048번 Iteration을 돌려버립니다. 브루트포싱할 때 그만큼 지연이 된다는 소리입니다. SHA1은 160비트 해시함수입니다. 해시가 20바이트의 길이를 가지죠. 이후 리턴되는 20바이트 문자열을 잘라서 앞 부분은 Key로 쓰고, 뒷부분은 다시 해싱을 해서 IV로 사용합니다.
- C로 짜면 다음과 같습니다.
- 이제 앞에서 얻은 IV, Key, Encrypted Data를 SEED 128 CBC 모드에서 복호화를 시도해 봅니다. 이 때 패딩이 제대로 되었는가, 헤더가 0x30으로 시작하는가, 즉 올바른 DER 인코딩인가를 검사하여 성공/실패 여부를 가립니다.
- 이제 BruteForceIterate 이 함수에서 성공하는 비번이 나올 때까지 계속 돌려봅니다.
- 이제 BruteForceIterate 함수를 호출해 성공하는 비번이 나올 때까지 계속 돌려봅니다. 속도는 하스웰 i7 기준 최대 초당 6800키 정도를 처리할 수 있었습니다. OpenCL로 포팅하는데 성공했다면 속도가 더 폭발적으로 증가했으리라 추측할 수 있습니다.
- 원래는 이렇게 나오는게 맞는데, 쓰레드끼리 꼬이더니 (클릭)
- 다음과 같은 결과가 나와버리는 경우가 생깁니다. 이것을 피하기 위한 코드를 따로 넣어주어야 했죠.
- 자! 이제 돌려봅시다.
- (클릭) (To 사용자) 특수문자/길게 : 그래야 레인보우 테이블에 공격당할 확률이 낮아집니다 주기적 변경 : 뚫을 때 많은 시간이 걸리는 해시함수 특성상, 뚫는데 두달 걸리는데 한달마다 바꾸면 해커가 포기하겠죠. (클릭) (To 크래커) 레인보우 테이블 하나 만들어서 계속 써먹던가, 끝내주는 그래픽카드로 GPGPU 돌려서 뚫어야겠죠.