Parker Falcon :: Grooving on the paper

영국은 열심히 알아보지 못하고 근처 마트에서 정말 간단하게 구입하였습니다.

운 좋게도 영국에서의 선불 SIM은 그냥 사서 충전만 하면 되는 것이었습니다.

역시나 당시 (2012년) 심 £5.00 에 충전 £15.00 하였습니다.

Pay As You Go - All in One £15.

http://store.three.co.uk/view/searchSimOnly?tariff=112

3000문자 / 300분 / 데이터 무제한

우리나라 핸드폰 요금과 영국의 물가를 감안해봤을 때 전혀 비싸지 않은 서비스입니다.

사실 2일 이상만 머물러도 본전이며, 일주일 정도 머물 때도 전혀 문제가 없었습니다.

(기억은 가물가물하지만 당시에 30일 정도의 유효기간으로 기억합니다.)

신분 확인이나 그런 것 없이 구매 가능하였으며, 핸드폰 ARS 통화를 통해서 영수증에 찍혀있는 코드 입력 하는 방법으로 충전하였습니다.

영국식 발음이라 다 알아듣지는 못하지만 충전을 top-up (탑업이 아니라 톱옵 정도의 발음)이라는 것만 알고 있으면 기본적인 영어 듣기 하에서 문제 없습니다.

당연한 이야기지만 지금은 심 크기 별로 (일반/마이크로/나노) 다 지원하고 있습니다.

[커버리지]

아쉽게도 런던과 인근 윈저성 정도만 방문하였지만 커버리지면에서는 문제가 없었습니다. 오히려 당시에는 지하철에서 너무나도 ‘당연하게’ 통신망이 안되어 당황했던 기억이 있습니다.

영국 전역에서 3G 망만 놓고 봤을때는 3가 우월하지만, 4G를포함한 LTE망을 놓고 보면 오랑쥬(Orange)와 티모바일이 함께 운영하는 EE가 커버리지가 조금 더 좋습니다. 하지만 대도시만 돌아다니는 정도에서는 큰 문제 없습니다.

다만 국내 출시된 iPhone 6/6+/5는 영국에서 3G/LTE 모두 문제 없어보이지만 5S의 경우는 LTE주파수 대역이 달라 3G만 사용할 수 있을 것으로 보입니다.

문제: 전자 서명 후 다시 암호화 하여 전송하는 것을 확인

yessign.EncryptData() 함수를 써서 암호화

저 작업 전에 yessign.PutOtherCert() 함수를 써서 암호화를 위한 인증서를 추가로 넣음

해당 인증서는 PEM형식 ("-----BEGIN CERTIFICATE-----“으로 시작해서 Base64데이터로 된 asn.1 형식 데이터 후 “-----END CERTIFICATE-----“로 종료) 으로 되어있음

1.2.840.113549.1.1.1 (oid rsaEncryption PKCS#1) 으로 된 1024비트 값과

1.2.840.113549.1.1.5 (oid sha1WithRSAEncryption PKCS #1) 으로 된 2048비트 값이 있다.

아무튼 이 키를 이용해서 암호화를 하면 역시나 3082로 시작하는 데이터가 나오는데, 이를 분석해보면 두 가지 값을 가진다.

1.2.840.113549.1.1.1 (oid rsaEncryption PKCS#1) 으로 된 128바이트 값 (=1024비트)

1.2.410.200004.1.4 (seedCBC Korean SEED algorithm, CBC mode) 값으로 “0123456789012345” 값과 16바이트 단위 블럭의 데이터들이 있다.

EncryptData 함수에 들어가는 메시지 길이와 무관하게 128바이트 값은 고정,

16바이트 단위 블러의 데이터 값은 16바이트 단위로 (128비트) 크기에 맞춰 변동.

이를 통해 위 값은 공개키 기반으로 한 암호화 한 데이터가 아닐까, (길이와 관계없이 그냥 암호화했거나, hash를 먹여서 암호화했거나)

아래 값은 SEED-CBC-128 로 암호화 한 것이 아닐까 (IV는 0123456789012345, 키는 알 수 없음)

그런데 처음에 입력 받은 키 값이 두 개가 있다.

1024비트와 2048비트 두 개가 있는데, 설마 개인키가 포함된 파일은 아닐것이다.

아무튼 1024비트 값과 2048비트 값을 둘 다 개별적으로 조작해보았는데, 어느 하나를 조작하더라도 결과로 나오는 128바이트/16바이트블럭 모두 영향을 받는 것으로 확인하였다.

이 값들이 어떻게 영향을 주는 것인지는 두고봐야되는데,

128바이트(1024비트) 고정 값은 해쉬 값이라고 보기에는 좀 길어 보여서 서명 값이 아닌가 추측해볼 수 있다. 하지만 키 값이랑 길이가 맞을지는 해 봐야 알 수 있고,

정작 어떤 데이터를 서명 했는지도 무식하게 대입해 보는 방법 밖에는 없다.

그리고 나머지 SEED-CBC-128로 암호화 한 것으로 보이는 데이터도 원본 키가 어떤 것인지 알 수 없는 문제가 남아있다.

(추가: 앞에 PEM형식 인증서에서 128바이트(1024비트)는 RSA암호화용 공개키, 256바이트(2048비트)는 서명이라고 합니다.)

비대칭키를 이용한 암호/서명

- 비대칭키: 개인키 및 공개키로 나누어 활용

- 공개키: 암호화 작업만 할 수 있음. 누구에게나 공개되어도 상관 없음

- 개인키: 복호화 작업을 위해 사용. 공개되면 안되는 키

디지털 서명

- '원래 자료'를 '해쉬'로 만든 다음,

- ‘개인 키'로 해당 해쉬 값을 ’암호화' 하고 (서명),

- 다른 사람들은 '원래 자료'를 '해쉬'로 만든 다음,

- 서명 값을 '공개 키'로 '복호화' 해서 비교하여

- 두 해쉬 값을 비교하여 일치하면 서명이 유효함.

즉 인증서를 통한 로그인시

- 사용자: 인증서의 고유 번호 + challenge 받은 메시지에 대한 서명 값을 server로 전송

- 서버: 해당 고유 번호에 등록된 공개키로 이 사용자가 서명한 값이 맞는지 확인 (검증은 공개키로 가능. 검증에 성공했다는 것은 이 사용자가 개인키를 가지고 있다는 이야기)

(실제 서버단에서는 어떤 다른 추가적인 방법이 있는지는 알 수 없으나 아무튼 정해서

공인인증서 관련 기술들

- http://www.rootca.or.kr/kor/standard/standard01B.jsp 를 참고

- 개인키: signPri.key 에 암호화 되어 들어있다.

- 공개키: signCert.der 에 들어있다.

- 인증서 발급처 마다 조금씩은 다르지만, 은행에서 발급 받은 yessign 공인인증서를 이용하여 테스트

공개키 파일

- signCert.der

- asn1 형식

- 안에 다시 asn1 형식

- 해당 파일이 PKCS#1인데 pub key 만 있었음

개인키 파일

- signPri.key

- PKCS#5 의 PBKDF1방식을 이용하여 복호화 한다. (키 파일에서 salt, integration count 를 구하고, 비밀번호는 공인인증서 비밀번호)

위 두 파일에 대한 처리 방법은 아래 링크를 참고

- https://gist.github.com/twkang/f5acf360c67ea0bf3f55

테스트해봅시다.

(파이선 코드)

원본(3): “abc”

sha256(64H/32B) ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

EME-PKCS1-v1_5 padding 처리 (msg = ‘abc’, key 길이 = 256, hash=sha256)

0001ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003031300d060960864801650304020105000420ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

(앞에 \x00\x01 붙이고, \xff로 쭉 채우고 \x00 붙이고 해쉬 종류에 따른 prefix 붙이고 abc에 대한 해쉬값을 붙인다.)

이 값을 개인키를 이용하여 ‘복호화’ 한다.

(암호화도 안했는데 왜 복호화부터 하냐고 묻지말자. 그냥 이렇게 정한것이다. 정말 PKI기반 디지털 서의 이론적인 원리가 궁금하다면 http://en.wikipedia.org/wiki/Digital_signature#How_they_work 를 참고하자.)

-> (256바이트/512Hex 데이터)

이 값이 서명값이고, 실제 플러그인에서 만들어 낸 서명문의 서명값과 일치한다.

(실제 플러그인 구동)

원본: SignData(‘abc’,’’,0)

결과값(3760H):

-> 3082...

여기서 뽑아낸 hash (512H/256B)

-> 26...76

이 hash에 대한 pubkey의 encrypt 결과 (510H/255B)

-> 01ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003031300d060960864801650304020105000420ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

서명(sign) : 복호화(decrypt)

검증(verify) == 암호화 후 메시지 같은지 비교

<실험>

서명 데이터를 다르게 했을 때 두 값이 달랐는데, 하나는 pkcs7-data(이게 아마 format에 맞춘게 아닐까), 나머지 하나가 해쉬.. 근데 그러면 pkcs7-data를 sign해야되나...

#1 mitmproxy 를 이용하여 트래픽 분석

#2 트래픽 일부 분석

#3 인증서 구조 분석

#4 서명 결과 분석

- ***** 사이트에서 로그인 시도

- yessignCrypto.js 스크립트에서 서명

- inputStr 에 서명할 데이터 포함 (timestamp 포함한 form data)

- yessignCrypto.SignData(inputStr, ssn, option) 을 통해 서명 (ssn, option에는 blank string)

- 공인인증서 로그인 창이 뜬 다음 서명 데이터 나온다 (여러번 요청해도 똑같은 데이터가 나옴 - 즉 서명 단계에서는 더이상 랜덤 값을 넣지 않는다)

- 이 결과(A)에 몇 가지 form data 를 추가하여 POST 요청

#5 결과(A)에 대한 분석

- 길이는 3966 바이트 (어느정도 변화 가능 - hex encoded 데이터)

- hex decode 결과는 약 1983 바이트 결과(A-1)

- 결과(A-1)은 30 82 로 시작하는 0x3082 == ASN.1 Sequence (http://etherhack.co.uk/asymmetric/docs/rsa_key_breakdown.html)

- 이 결과(A-1)를 파일로 저장하여 openssl 로 열어봅시다

- $ openssl asn1parse -in FILENAME -inform der

- pkcs7-data 로 174바이트의 hex encoded 데이터 (hex decode 후 euc-kr 로 decode시 원본 서명 텍스트 나옴)

- rsaEncryption 로 512바이트의 hex encoded 데이터 (hex decode 후 256바이트의 raw data)

- sha256WithRSAEncryption 로 2048비트(256바이트)의 이진수 데이터 (raw data). RSA암호 후 이걸로 해쉬하면 이게 나오나

- 특별히 이름은 없는데 270바이트짜리 2진수 raw data도 존재. 서명 단계에서 원본값을 변조한 결과 변경되지 않으므로 무시.

- 즉 sha256WithRSAEncryption 값이 서명 데이터임을 알 수 있음

#6 서명데이터(256바이트)에 대한 분석

- object tag를 통해 active x 를 호출하는 과정에서, 같은 인증서를 이용한 경우 해쉬 값에는 오로지 메시지만 영향을 주는 것을 확인

-> 즉 메시지에 대한 서명값

#* 기타

- 전자 서명문은 PKCS#7 을 이용