Parker Falcon :: Grooving on the paper

와!

파이선으로 공인인증서 다루기 위해 노력한 성과가 나왔습니다.

PyPinkSign으로 이름붙인 모듈입니다.

https://github.com/bandoche/PyPinkSign

를 확인하시면 됩니다.

기본적인 기능들이 지원됩니다.

(공인인증서 읽기, sign, verify, encrypt, decrypt)

또한 일부 PKCS#7의 sign 및 envelop 기능도 지원됩니다.

자세한 내용은 위 github 페이지를 이용해주세요.

흔히 TravelSim이나 비슷한 명칭의 다른 심카드로 다양한 국가에서 심 카드 사용을 고민해볼 수 있습니다.

결론만 말하면 좋은 선택은 아닙니다. 다만 개인 시간이 거의 없는 패키지여행이라면 고려해볼만은 합니다.

왜냐면 국가 마다 선불 카드를 구매하기 위해 시간을 따로 투자할 필요가 없기 때문입니다.

다만 가격 대비 제공 용량이 매우 적으므로 텍스트 정보 검색 외에는 사진 업로드 몇 장 안됩니다.

또한 나라마다 데이터 요금이 패키지요금으로 저렴하게 차감되는지, 아니면 비싼 사용용량별 요금으로 청구되는지가 달라집니다.

꼭 방문하는 국가가 어떤 형태의 요금으로 제공되는지 확인하시기 바랍니다.

더군다나 패키지 여행에서는 직접 검색할 일이 상대적으로 적다는 점도 생각합시다.

* 짧은 기간에 다양한 나라를 지나는데 데이터를 써야된다 - 짧은 기간이니 차라리 국내 통신사의 일일무제한 로밍을 사용합니다.

* 나라에서 3~4일 이상 있고 데이터를 써야된다 - 현지에서 심카드를 구매하여 사용하는 것이 저렴합니다.

* 다양한 나라를 짧은 기간에 지나면서 데이터를 아주 조금 써야된다 - 사용해볼만 합니다. (짧은 기간은 1일~2일, 데이터는 텍스트나 아주 단순한 이미지 정도. 이미지 업로드로 사용하기엔 비쌉니다.)

고민이 된다면 차라리 데이터를 절약할 수 있는 방법을 알아봅시다.

* 지도는 미리 다운로드 받아서 오프라인 지도를 활용할 수 있습니다.

대신 핸드폰에서 로밍 기능을 끄고 셀룰러 데이터를 끄고 GPS만 켜두면, 현 위치도 확인 가능합니다. 대신 처음에 위치 잡는게 오래 걸립니다.

(스마트폰에서의 위치서비스는 GPS외에도 Wi-Fi 와 통신기지국 정보를 활용하여 데이터가 소모되므로 데이터 요금 폭탄에 주의합시다.)

* 실시간으로 연락을 확인해야 되는 경우가 아니면 필요한 경우에만 셀룰러 데이터를 활성화 합시다.

* 불필요한 앱은 삭제하고, 동기화 기능은 최대한 끕시다.

제일 힘들었던 경험입니다.

http://www.orange.fr

프랑스의 통신사 오랑쥬입니다. 오렌지라고 읽었다가 아무도 못알아 들었던 경험이 있네요.

영국이랑 비슷하다 생각해고 근처 마트에서 구매 했다가 제대로 쓰지도 못했습니다.

일단 말이 안통하는데 더군다나 주말인가 해서 구하기도 힘들었는데, 사려고 할 때 이상한 서류를 주면서 이걸 작성해서 보내야

완료라고 할 때 뭔가 잘못된 것을 깨닳아야되었습니다.

결국 평일날 orange 대리점 (샹젤리제 거리에 있던 곳을 갔습니다.) 가서 영어로 상황을 설명한 다음 활성화 요청을 하였습니다.

영국과는 다르게 신분증을 등록하여 사용하였으며, 다음날 되었던 것으로 기억합니다.

심지어 핸드폰을 통한 인증 과정도 프랑스어로 나와서 제대로 활용하지 못했습니다.

(당시에 구매하면서 심 카드를 선택할 수 없어서 4s에 맞게 잘라서 사용했습니다.)

어쨋든 이 정책은 프랑스 전역에 동일한 것으로 보이므로 가능하면 통신사 직영점을 직접 방문하여 구매하도록 합시다.

semaine internet max / €7.00 로 일주일 무제한 요금제였습니다.

지금은 당시와는 다르게 데이터 전용 선불 심을 €9.90에 사면 500MB데이터(1달)가 포함되고, 충전 요금 별로 데이터/유효기간이 다른 서비스를 받을 수 있습니다. (3유로-200메가-1일 / 10유로-1기가-7일 / 20유로-2기가-31일 / 35유로-3기가/6달 )

[커버리지]

역시 프랑스 대부분을 커버하고 있어 사용에 문제 없었습니다. 일부 실내에서 잘 안되었던 것 으로 기억합니다. (이틀 밖에 쓰지 못해 제대로 확인해볼 수 없었습니다.)

충전에 성공하면 위와 같이 확인할 수 있습니다.

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

운 좋게도 영국에서의 선불 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 을 이용

- 간단 리뷰 : 운 좋게 초청권 받아서 본 연극. 등장 캐릭터가 좀 많고 국사에 약간 관심이 있으면 (몇 몇 유명 인물 나오는 정도) 조금 재미있긴 할 수도 있다.

정작 관람 당시 여러 건의 시행 착오 (조명 조절 실수 / 음악 재생 실수) 와, 애드립의 애매함 (한 두번은 상관없는데 여러번 하면 망할 개그들..) 에다가 연극 내용의 아쉬움이 더해져 약간 실망.

내용을 조금 더 다듬으면 좋았을 것 같다. 여러 씬에서 군더더기와 부조화가 느껴진다. 필요없는 대사는 조금 줄여도 좋을 것 같고, 분위기와 맞지 않는 개그 코드/타이밍은 작가의 개그 감을 의심하게 만들었다.