플러그인 기술이 미약할때 ssl이 있었는데 그 당시 RSA export 문제로 인해 미국을 제외한 나라에서는 128비트 ssl이 안되었죠. 그래도 나온 방법이 http proxy 방식을 이용한 ssl이였고 그후 https는 http 채널 자체를 보호하는 방식이라 이미지를 포함하는 사이트에서는 힘들어 졌죠.
SET 이 전자 상거래용으로 만들어졌는데 이게 구현상 어렵고 복잡해서 이 방식 보다는 plug-in을 사용하게 되었습니다. 특히 우리나라가 이쪽으로는 공인인증서 연동까지 해서 요즘은 ssl 사용하는 쇼핑몰은 찾아 보기 힘듭니다. 물론 IE의 대세가 한목하긴 했지만요.
https는 단순히 id/password로 로그인할때 그쯤에서만 사용합니다. 그래도 외국에서는 대부분 https 기반입니다. 아마존만 봐도 알수 있죠. 인터넷 뱅킹도 우리처럼 사용하는 곳은 아직 없죠. 인증서는 말할 필요도 없이요.
정말 우리나라는 IT 강국이긴 합니다. 아직 생산/개발 시스템은 좀 많이 부족하지만 인프라 규모면에서는 강국이죠.
https 가 http over SSL 입니다.
https는 단순히 id/password로 로그인할때 그쯤에서만 사용합니다. 그래도 외국에서는 대부분 https 기반입니다. 아마존만 봐도 알수 있죠. 인터넷 뱅킹도 우리처럼 사용하는 곳은 아직 없죠. 인증서는 말할 필요도 없이요.
정말 우리나라는 IT 강국이긴 합니다. 아직 생산/개발 시스템은 좀 많이 부족하지만 인프라 규모면에서는 강국이죠.
저는 이 측면에서 우리가 IT 강국이라고 보기 어렵다고 생각합니다.
물론 우리 나라가 128bit SSL이 미국 외 국가에 수출이 되기 전에 스스로 자체 암호 알고리듬을 만들고, 인증 규격을 만들어 구현 했다는 점은 높이 살 만합니다. 그러나 기술이 좋았다면 이미 IE나 Mozilla 같은 곳에 암호화 기술이 탑재되어 있어야 한다고 봅니다. 그런 노력이 등한시 되어 꼼수로 ActiveX 플러그인을 만들게 되고, 공인인증 클라이언트 기술이 이제 ActiveX에 종속적이 되어 버렸지요. (깔리는 플러그인만 스무개가 넘죠. 은행권, 카드사, 증권사, PG사 등등..)
다른 나라는 SSL over HTTP 기술(https)과 client certificate 인증 기술을 이용해 인터넷 뱅킹 및 전자 투표로 시행하고 있습니다. 우리 나라 같은 공인 인증 체계가 있는 것이 기술적으로 우월하다고 보이지 않습니다. 오히려 국제 규격이나 표준에 따라가지 못한 우물안 개구리식 서비스 구현으로 밖에 보이지 않습니다. 다른 나라 다 쉽게 하고 있는 걸 우리나라만 어렵게 만든 거 밖에 안되죠.
외국이 우리 나라 같은 구조로 따라올 가능성은 없어 보입니다. 최근 kisa가 노력해서 중국이나 동남아에서 따라올 것 같지만 리눅스같은 대안 데스크톱에 대한 대안 기술이 없는 상태에서 쉽지 않겠지요.
SSL을 쓰는 것이 더 후진 적인 것이 아닙니다. 공인 인증 같은 인증서 기반 서비스나 암호화 모두 가능합니다.
지금 까지 정부에서 해 온 일은 국제 표준을 무시하고 수 많은 우리나라 보안 업체를 먹여 살리기 위한 선택을 해 온 것 밖에 없죠.
뭔가 오해가 있으시군요. SSL 대신 플러그인을 써서 구현했다고 해서 강국이라고 표현하지는 않았습니다.
SSL이 보안성을 제공 하지만 E2E 보안이라 무겁기도 하고 무인봉쇄를 지원하지는 않습니다. 우리나라 전자 상거래에서 SSL을 쓰지 않는 이유중에 하나가 PG업에 있습니다. PG업체가 시장을 먹으면서 SSL보다는 플러그인 방식을 선호 했기 때문이기도 합니다. 당시에는 복잡한 SET 보다는 플러그인 기술이 더 용이했습니다. 그리고 RSA의 128비트 export 제한도 한목 했구요.
국제 표준을 완전히 무시하면서 사용하고 있지는 않습니다. 수용하는 측면에서 사용하고 있는겁니다. 국내 표준도 X.509 Profile을 준용하고 있습니다.
어떤 점에서 국제 표준을 무시했다고 하는지 예를 드는 편이 알기 쉽겠습니다.
channy wrote:
김충길 wrote:
https 가 http over SSL 입니다.
https는 단순히 id/password로 로그인할때 그쯤에서만 사용합니다. 그래도 외국에서는 대부분 https 기반입니다. 아마존만 봐도 알수 있죠. 인터넷 뱅킹도 우리처럼 사용하는 곳은 아직 없죠. 인증서는 말할 필요도 없이요.
정말 우리나라는 IT 강국이긴 합니다. 아직 생산/개발 시스템은 좀 많이 부족하지만 인프라 규모면에서는 강국이죠.
저는 이 측면에서 우리가 IT 강국이라고 보기 어렵다고 생각합니다.
물론 우리 나라가 128bit SSL이 미국 외 국가에 수출이 되기 전에 스스로 자체 암호 알고리듬을 만들고, 인증 규격을 만들어 구현 했다는 점은 높이 살 만합니다. 그러나 기술이 좋았다면 이미 IE나 Mozilla 같은 곳에 암호화 기술이 탑재되어 있어야 한다고 봅니다. 그런 노력이 등한시 되어 꼼수로 ActiveX 플러그인을 만들게 되고, 공인인증 클라이언트 기술이 이제 ActiveX에 종속적이 되어 버렸지요. (깔리는 플러그인만 스무개가 넘죠. 은행권, 카드사, 증권사, PG사 등등..)
다른 나라는 SSL over HTTP 기술(https)과 client certificate 인증 기술을 이용해 인터넷 뱅킹 및 전자 투표로 시행하고 있습니다. 우리 나라 같은 공인 인증 체계가 있는 것이 기술적으로 우월하다고 보이지 않습니다. 오히려 국제 규격이나 표준에 따라가지 못한 우물안 개구리식 서비스 구현으로 밖에 보이지 않습니다. 다른 나라 다 쉽게 하고 있는 걸 우리나라만 어렵게 만든 거 밖에 안되죠.
외국이 우리 나라 같은 구조로 따라올 가능성은 없어 보입니다. 최근 kisa가 노력해서 중국이나 동남아에서 따라올 것 같지만 리눅스같은 대안 데스크톱에 대한 대안 기술이 없는 상태에서 쉽지 않겠지요.
SSL을 쓰는 것이 더 후진 적인 것이 아닙니다. 공인 인증 같은 인증서 기반 서비스나 암호화 모두 가능합니다.
지금 까지 정부에서 해 온 일은 국제 표준을 무시하고 수 많은 우리나라 보안 업체를 먹여 살리기 위한 선택을 해 온 것 밖에 없죠.
뭔가 오해가 있으시군요. SSL 대신 플러그인을 써서 구현했다고 해서 강국이라고 표현하지는 않았습니다.
그런 의미가 문맥에 있는 것 같아서요. 사과드립니다.
김충길 wrote:
SSL이 보안성을 제공 하지만 E2E 보안이라 무겁기도 하고 부인봉쇄를 지원하지는 않습니다.
https의 경우, 클라인트 인증과 verisign pta같은것을 써서 부인 봉쇄를 지원합니다. 문제는 사용자 입장에서 os dependant된 기술이냐 아니냐가 중요한것이죠.
김충길 wrote:
우리나라 전자 상거래에서 SSL을 쓰지 않는 이유중에 하나가 PG업에 있습니다. PG업체가 시장을 먹으면서 SSL보다는 플러그인 방식을 선호 했기 때문이기도 합니다.
플러그인을 썼던 회사는 I사 밖에 없습니다. 거의 대부분의 PG사들이 SSL redirect 방식을 썼었죠. (ksnet, kcp 기타 등등..) 지금도 자체 플러그인을 가지고 있는 회사는 I사 밖에 없습니다.
오히려 kisa가 주도한 공인 인증 규격때문에 은행, 증권사 플러그인이 더 늘어난 것이죠. PG는 신용카드에 공인 인증 붙이기 전까지는 없었습니다. 브라우저 및 플랫폼 호환성 문제에 대해 kisa 사람들이 하는 말... "우리는 그걸 다 지원하라고 했다. 단지 돈이 많이 드니까 안하는 것 뿐"..
김충길 wrote:
국제 표준을 완전히 무시하면서 사용하고 있지는 않습니다. 수용하는 측면에서 사용하고 있는겁니다. 국내 표준도 X.509 Profile을 준용하고 있습니다.
어떤 점에서 국제 표준을 무시했다고 하는지 예를 드는 편이 알기 쉽겠습니다.
공인인증 규격 자체가 PKI와 x.509표준을 지키는 것은 맞습니다. 제가 이야기한 것은 서비스 측면에서 암호 알고리듬 및 브라우저 단 구현 기술에 대한 국제적 경향을 이야기 한 것입니다. 사용자에게 문제를 모두 부가한 채, 표준 규격에 맞는 기술을 가졌다고 바른 것은 아니라고 봅니다.
PG는 제가 잘 모르겠고, 인증서를 이용한 국내 인터넷 뱅킹 시스템 구축도 그 프로토콜은 SSL 입니다.
아시다시피 SSL은 크게 인증 방식에 따라 클라이언트, 서버, 양방향, 어나니 이렇게 4가지 운영모드로 나뉘는데 일반적인 https:// 접속은 서버 인증만 수행하는 것이 대다수입니다. 다시 말해 서버의 X.509 인증서를 통해 엄밀하지 않게 서버 인증을 마치고 SSL프로토콜로 얻어진 안전한 세션키를 이용해 네트웍 세션 암호화에 중점을 두는 것이죠.
하지만, 이는 클라이언트 인증을 하지 않음으로써 금융거래 등에 그대로 적용하는 것은 무리가 있습니다. IE도 브라우져에서 양방향 인증을 이용해 접속할 수 있지만 개인 인증서 선택도 잘 안되고 무쟈게 불편합니다. 또한 IE에서 지원안하는 알고리즘을 요구 합니다. 따라서 이를 용이하게 해주는 helper 프로그램이 필요했고 이를 Active-X 형태로 구현 인증서를 선택하고 암호 연산을 하게 했죠.
helper는 양방향 인증 구현을 위한 어쩔 수 없는 선택이었다는 말입니다.
그럼 왜 구현은 ActiveX이냐, Java로 하면 어떠냐. 초창기에 자바로 하려는 노력이 없었던 것은 아니지만 BMT 등에서 속도(암호 연산은 시간이 무쟈게 걸리죠. 뭐 JNI로 빼도 되지만, 이건 더 이상 자바로 부르기엔)등에 문제가 생기면서 열외로 되었습니다.
그럼 뭐, 모질라 플럭인은? 예전에 사용되었지만 IE로 대세가 굳혀지면서 폐기되었습니다.
우리나라는 공인인증서에 주민등록 관련 정보를 삽입함으로써 공인인증서가 굉장한 위력을 갖습니다. 일례로 요즘 점점 사이트에 ID & PW 없이도 로긴할 수 있는 사이트가 생기지 않나요? 공인인증서 로긴만 받으면 신원확인이 가능하므로 따로 패스워드 등을 받을 필요가 없죠.
공인인증서를 활용하여 PKI 인프라구축하는 레벨은 단연 우리나라가 앞서 있는 것은 사실입니다.
문제는 플랫폼 종속적인 측면인데, 이는 자바등으로 helper들이 구현된다면 해결 되겠지요.
뭐, 요즘 자바 속도도 빨라지고, 애플릿 형태에서 로컬 파일 읽는 보안 문제도 사라지고 했으니, 유럽쪽에서는 이를 이용해 인터넷 뱅킹을 구현한 곳이 있는걸로 알고 있습니다.
PG는 제가 잘 모르겠고, 인증서를 이용한 국내 인터넷 뱅킹 시스템 구축도 그 프로토콜은 SSL 입니다.
엄밀히 말하면 틀리죠. 세션키를 만들고 그걸로 암호화 해서 보냈다 라고 해서 SSL이라고 한다면 SSL이 울지도 ...
뱅킹이나 안심결제나 다 PKCS7으로 하는걸로 알고 있는데 아닌가요?
어떤 밑 글이 달렸나 궁금해서 들어와봤는데... 음냐, 간략히 말씀 드리죠.
국내 인터넷 뱅킹 프로토콜 SSL 맞습니다. 패킷 덤프 함 떠보시면 알 수 있을테고요. SSL이란 것은 PKI를 이용해서 양자간에 신원 인증(authentication), 기밀성(secrecy, privacy), 무결성(데이터 인증, integrety)를 제공하는 complete한 프로토콜 입니다.
따라서 네트웍을 통한 위의 요건을 만족하는 프로토콜은 설계 하다보면 다 SSL like한 프로토콜이 됩니다. 이러니 그냥 SSL 쓰고 말지요.
만일 독자적인 무슨 프로토콜을 설계하려 한다면 보안성 심의 문서에 그 프로토콜이 안전하다는 것을 증명해야 하는데, 이럴바에야 잘 증명된 SSL 쓰겠죠?
PKCS#7은 PKI기술을 이용한 문서에 대한 서명,암호화 등을 규약하는 표준입니다. 전 세계 어떤 서비스도 네트웍 스트림에 PKCS#7 표준을 적용하지는 않습니다. 다만 서비스 중 중요시 되는 전문 등의 문서를 이를 이용 서명 & 암호화할 뿐이지요.
예를 들어 보안 메일 S/MIME 등이 PKCS#7을 이용한 서비스라고 보심 됩니다. 말씀하신대로, 뱅킹이나 PG에서 PKCS#7 씁니다. 그렇다고 그걸 일반 페이지에서 계좌 정보등이 들어있는 웹페이지에 적용하는 것이 아니란 말이죠. 그건 SSL의 세션 암호화로 해결 합니다.
참, SSL/TLS에 대해서 더 궁금하신 분은 Eric Rescola 가 쓴 SSL/TLS책 보세요.
우리나라 plugin 방식의 인터넷 뱅킹을 얘기 하는 건가요? 블러그인 방식은 네트웍 스트림으로 보긴 힘들죠. 메시지를 싼 다음에 http 올려서 날라가니. 플러그인이 따로 서버쪽으로 채녈을 가지고 있다면 얘기는 틀려지겠네요.
업체마다 차이가 있는걸로 알고 있습니다만 whbear께서 덥프 해보셨다는 은행이 어디 인가요? S사가 구축한 은행인가요?
흠냐, 덤프까진 떠보진 않았지만, 님께서 말씀하신 S사(제 짐작이 맞다면)의 구현은 플럭인이 따로 채널을 갖고 있습니다. 그리고 전 그 S사 직원이었더랬습니다.
뭔가 님과 용어상의 혼돈이 있을지 모르겠지만, 뭐 예를 들어 서비스 자체가 문서 1-2개 보내주고 1-2개 받는 정도라면(PG처럼) 그냥 1-2개 문서에 대해서 PKCS#7으로 서명(+암호화)까지 하면 되겠지만, 인터넷 뱅킹 처럼 접속해서 웹페이지를 계속 보게되고 이의 기밀성이 요구된다면 PKCS#7 구현으로 못합니다. PKCS#7은 각 엔터티마다 RSA개인키로 서명하거나 받는 사람이 RSA개인키로 복호화해야 하는데 그 연산량이란 장난이 아니죠!
IIS 에 들어있는 마소 원격 관리 프로그램(웹브라우저로)에서도 쓰입니다
IIS 에 들어있는 마소 원격 관리 프로그램(웹브라우저로)에서도 쓰입니다.
----
블로그 / 위키 / 리눅스 스크린샷 갤러리
https 가 http over SSL 입니다.플러그인 기술이 미
https 가 http over SSL 입니다.
플러그인 기술이 미약할때 ssl이 있었는데 그 당시 RSA export 문제로 인해 미국을 제외한 나라에서는 128비트 ssl이 안되었죠. 그래도 나온 방법이 http proxy 방식을 이용한 ssl이였고 그후 https는 http 채널 자체를 보호하는 방식이라 이미지를 포함하는 사이트에서는 힘들어 졌죠.
SET 이 전자 상거래용으로 만들어졌는데 이게 구현상 어렵고 복잡해서 이 방식 보다는 plug-in을 사용하게 되었습니다. 특히 우리나라가 이쪽으로는 공인인증서 연동까지 해서 요즘은 ssl 사용하는 쇼핑몰은 찾아 보기 힘듭니다. 물론 IE의 대세가 한목하긴 했지만요.
https는 단순히 id/password로 로그인할때 그쯤에서만 사용합니다. 그래도 외국에서는 대부분 https 기반입니다. 아마존만 봐도 알수 있죠. 인터넷 뱅킹도 우리처럼 사용하는 곳은 아직 없죠. 인증서는 말할 필요도 없이요.
정말 우리나라는 IT 강국이긴 합니다. 아직 생산/개발 시스템은 좀 많이 부족하지만 인프라 규모면에서는 강국이죠.
screen + vim + ctags 좋아요~
국내도 HSBC 인터넷 뱅킹은 HTTPS로 동작합니다.거의 대부분
국내도 HSBC 인터넷 뱅킹은 HTTPS로 동작합니다.
거의 대부분의 해외의 쇼핑볼 등이 HTTPS를 사용하는 관계로 SSL 고속화를 위한 솔루션이 많이 이용되는데(SSL 엑셀러레이터나 Akamai의 SSL CDN서비스등) 국내에서는 그렇게까지는 이용이 안되는것 같네요. 공인인증서 + ActiveX 가 있으니까...
--
익스펙토 페트로눔
SSL은
저는 이 측면에서 우리가 IT 강국이라고 보기 어렵다고 생각합니다.
물론 우리 나라가 128bit SSL이 미국 외 국가에 수출이 되기 전에 스스로 자체 암호 알고리듬을 만들고, 인증 규격을 만들어 구현 했다는 점은 높이 살 만합니다. 그러나 기술이 좋았다면 이미 IE나 Mozilla 같은 곳에 암호화 기술이 탑재되어 있어야 한다고 봅니다. 그런 노력이 등한시 되어 꼼수로 ActiveX 플러그인을 만들게 되고, 공인인증 클라이언트 기술이 이제 ActiveX에 종속적이 되어 버렸지요. (깔리는 플러그인만 스무개가 넘죠. 은행권, 카드사, 증권사, PG사 등등..)
다른 나라는 SSL over HTTP 기술(https)과 client certificate 인증 기술을 이용해 인터넷 뱅킹 및 전자 투표로 시행하고 있습니다. 우리 나라 같은 공인 인증 체계가 있는 것이 기술적으로 우월하다고 보이지 않습니다. 오히려 국제 규격이나 표준에 따라가지 못한 우물안 개구리식 서비스 구현으로 밖에 보이지 않습니다. 다른 나라 다 쉽게 하고 있는 걸 우리나라만 어렵게 만든 거 밖에 안되죠.
외국이 우리 나라 같은 구조로 따라올 가능성은 없어 보입니다. 최근 kisa가 노력해서 중국이나 동남아에서 따라올 것 같지만 리눅스같은 대안 데스크톱에 대한 대안 기술이 없는 상태에서 쉽지 않겠지요.
SSL을 쓰는 것이 더 후진 적인 것이 아닙니다. 공인 인증 같은 인증서 기반 서비스나 암호화 모두 가능합니다.
지금 까지 정부에서 해 온 일은 국제 표준을 무시하고 수 많은 우리나라 보안 업체를 먹여 살리기 위한 선택을 해 온 것 밖에 없죠.
Channy Yun
Mozilla Korean Project
http://www.mozilla.or.kr
Re: SSL은
뭔가 오해가 있으시군요. SSL 대신 플러그인을 써서 구현했다고 해서 강국이라고 표현하지는 않았습니다.
SSL이 보안성을 제공 하지만 E2E 보안이라 무겁기도 하고 무인봉쇄를 지원하지는 않습니다. 우리나라 전자 상거래에서 SSL을 쓰지 않는 이유중에 하나가 PG업에 있습니다. PG업체가 시장을 먹으면서 SSL보다는 플러그인 방식을 선호 했기 때문이기도 합니다. 당시에는 복잡한 SET 보다는 플러그인 기술이 더 용이했습니다. 그리고 RSA의 128비트 export 제한도 한목 했구요.
국제 표준을 완전히 무시하면서 사용하고 있지는 않습니다. 수용하는 측면에서 사용하고 있는겁니다. 국내 표준도 X.509 Profile을 준용하고 있습니다.
어떤 점에서 국제 표준을 무시했다고 하는지 예를 드는 편이 알기 쉽겠습니다.
screen + vim + ctags 좋아요~
Re: SSL은
그런 의미가 문맥에 있는 것 같아서요. 사과드립니다.
https의 경우, 클라인트 인증과 verisign pta같은것을 써서 부인 봉쇄를 지원합니다. 문제는 사용자 입장에서 os dependant된 기술이냐 아니냐가 중요한것이죠.
플러그인을 썼던 회사는 I사 밖에 없습니다. 거의 대부분의 PG사들이 SSL redirect 방식을 썼었죠. (ksnet, kcp 기타 등등..) 지금도 자체 플러그인을 가지고 있는 회사는 I사 밖에 없습니다.
오히려 kisa가 주도한 공인 인증 규격때문에 은행, 증권사 플러그인이 더 늘어난 것이죠. PG는 신용카드에 공인 인증 붙이기 전까지는 없었습니다. 브라우저 및 플랫폼 호환성 문제에 대해 kisa 사람들이 하는 말... "우리는 그걸 다 지원하라고 했다. 단지 돈이 많이 드니까 안하는 것 뿐"..
공인인증 규격 자체가 PKI와 x.509표준을 지키는 것은 맞습니다. 제가 이야기한 것은 서비스 측면에서 암호 알고리듬 및 브라우저 단 구현 기술에 대한 국제적 경향을 이야기 한 것입니다. 사용자에게 문제를 모두 부가한 채, 표준 규격에 맞는 기술을 가졌다고 바른 것은 아니라고 봅니다.
Channy Yun
Mozilla Korean Project
http://www.mozilla.or.kr
PG는 제가 잘 모르겠고, 인증서를 이용한 국내 인터넷 뱅킹 시스템 구축
PG는 제가 잘 모르겠고, 인증서를 이용한 국내 인터넷 뱅킹 시스템 구축도 그 프로토콜은 SSL 입니다.
아시다시피 SSL은 크게 인증 방식에 따라 클라이언트, 서버, 양방향, 어나니 이렇게 4가지 운영모드로 나뉘는데 일반적인 https:// 접속은 서버 인증만 수행하는 것이 대다수입니다. 다시 말해 서버의 X.509 인증서를 통해 엄밀하지 않게 서버 인증을 마치고 SSL프로토콜로 얻어진 안전한 세션키를 이용해 네트웍 세션 암호화에 중점을 두는 것이죠.
하지만, 이는 클라이언트 인증을 하지 않음으로써 금융거래 등에 그대로 적용하는 것은 무리가 있습니다. IE도 브라우져에서 양방향 인증을 이용해 접속할 수 있지만 개인 인증서 선택도 잘 안되고 무쟈게 불편합니다. 또한 IE에서 지원안하는 알고리즘을 요구 합니다. 따라서 이를 용이하게 해주는 helper 프로그램이 필요했고 이를 Active-X 형태로 구현 인증서를 선택하고 암호 연산을 하게 했죠.
helper는 양방향 인증 구현을 위한 어쩔 수 없는 선택이었다는 말입니다.
그럼 왜 구현은 ActiveX이냐, Java로 하면 어떠냐. 초창기에 자바로 하려는 노력이 없었던 것은 아니지만 BMT 등에서 속도(암호 연산은 시간이 무쟈게 걸리죠. 뭐 JNI로 빼도 되지만, 이건 더 이상 자바로 부르기엔)등에 문제가 생기면서 열외로 되었습니다.
그럼 뭐, 모질라 플럭인은? 예전에 사용되었지만 IE로 대세가 굳혀지면서 폐기되었습니다.
우리나라는 공인인증서에 주민등록 관련 정보를 삽입함으로써 공인인증서가 굉장한 위력을 갖습니다. 일례로 요즘 점점 사이트에 ID & PW 없이도 로긴할 수 있는 사이트가 생기지 않나요? 공인인증서 로긴만 받으면 신원확인이 가능하므로 따로 패스워드 등을 받을 필요가 없죠.
공인인증서를 활용하여 PKI 인프라구축하는 레벨은 단연 우리나라가 앞서 있는 것은 사실입니다.
문제는 플랫폼 종속적인 측면인데, 이는 자바등으로 helper들이 구현된다면 해결 되겠지요.
뭐, 요즘 자바 속도도 빨라지고, 애플릿 형태에서 로컬 파일 읽는 보안 문제도 사라지고 했으니, 유럽쪽에서는 이를 이용해 인터넷 뱅킹을 구현한 곳이 있는걸로 알고 있습니다.
제 글에 오타가 있었네요. 무인봉쇄가 아니라 부인봉쇄입니다.ver
제 글에 오타가 있었네요. 무인봉쇄가 아니라 부인봉쇄입니다.
verisign pta가 뭔지 모르겠지만 SSL(또는 TLS) 프로토콜에서는 트랜젝션에 대한 부인봉쇄 메카니즘이 없는걸로 알고 있습니다.
Verisign PTA는 제가 잘 몰라서 언급할 수 없군요.
https 전송전에 PTA와 인터페이스가 있고 여기게 전송 데이타에 대한 서명을 추가해서 보내는 방법이 있는 건가요?
screen + vim + ctags 좋아요~
[quote="whbear"]PG는 제가 잘 모르겠고, 인증서를 이용한
엄밀히 말하면 틀리죠. 세션키를 만들고 그걸로 암호화 해서 보냈다 라고 해서 SSL이라고 한다면 SSL이 울지도 ...
뱅킹이나 안심결제나 다 PKCS7으로 하는걸로 알고 있는데 아닌가요?
screen + vim + ctags 좋아요~
질문자 입니다.알아들을것 같기도 한데.. 제가 잘 못알아 듣겠네요..
질문자 입니다.
알아들을것 같기도 한데.. 제가 잘 못알아 듣겠네요.. ^^;
플러그인을 이용:
클라이언트 pc에 프로그램이 설치되고 서버와 데이타 주고받을시
pc에 설치된 프로그램에서 암호화하고 서버에서는 이를 복호화..
안전하고 정확한 데이타 송수신
https :
위의 글중에 E2E보안, 서버인증이라고 되어 있던데.. 대략무엇을 의미하는지
쉽게좀.. ^^;
그리고 은행과 카드사에서 일해본적이 있는데 이들은 모두 플러그인을
이용해서 암호화를 했습니다.
물론 제공업체에 소프트웨어 사용료를 지불해야 하죠..
https를 사용하려면 특정한 제품을 구입하는건지.
아니면 웹서버에서 제공되는건지..
[quote="김충길"][quote="whbear"]PG는 제가 잘 모르
어떤 밑 글이 달렸나 궁금해서 들어와봤는데... 음냐, 간략히 말씀 드리죠.
국내 인터넷 뱅킹 프로토콜 SSL 맞습니다. 패킷 덤프 함 떠보시면 알 수 있을테고요. SSL이란 것은 PKI를 이용해서 양자간에 신원 인증(authentication), 기밀성(secrecy, privacy), 무결성(데이터 인증, integrety)를 제공하는 complete한 프로토콜 입니다.
따라서 네트웍을 통한 위의 요건을 만족하는 프로토콜은 설계 하다보면 다 SSL like한 프로토콜이 됩니다. 이러니 그냥 SSL 쓰고 말지요.
만일 독자적인 무슨 프로토콜을 설계하려 한다면 보안성 심의 문서에 그 프로토콜이 안전하다는 것을 증명해야 하는데, 이럴바에야 잘 증명된 SSL 쓰겠죠?
PKCS#7은 PKI기술을 이용한 문서에 대한 서명,암호화 등을 규약하는 표준입니다. 전 세계 어떤 서비스도 네트웍 스트림에 PKCS#7 표준을 적용하지는 않습니다. 다만 서비스 중 중요시 되는 전문 등의 문서를 이를 이용 서명 & 암호화할 뿐이지요.
예를 들어 보안 메일 S/MIME 등이 PKCS#7을 이용한 서비스라고 보심 됩니다. 말씀하신대로, 뱅킹이나 PG에서 PKCS#7 씁니다. 그렇다고 그걸 일반 페이지에서 계좌 정보등이 들어있는 웹페이지에 적용하는 것이 아니란 말이죠. 그건 SSL의 세션 암호화로 해결 합니다.
참, SSL/TLS에 대해서 더 궁금하신 분은 Eric Rescola 가 쓴 SSL/TLS책 보세요.
[quote="whbear"]PKCS#7은 PKI기술을 이용한 문
우리나라 plugin 방식의 인터넷 뱅킹을 얘기 하는 건가요? 블러그인 방식은 네트웍 스트림으로 보긴 힘들죠. 메시지를 싼 다음에 http 올려서 날라가니. 플러그인이 따로 서버쪽으로 채녈을 가지고 있다면 얘기는 틀려지겠네요.
업체마다 차이가 있는걸로 알고 있습니다만 whbear께서 덥프 해보셨다는 은행이 어디 인가요? S사가 구축한 은행인가요?
screen + vim + ctags 좋아요~
[quote="김충길"]우리나라 plugin 방식의 인터넷 뱅킹을
흠냐, 덤프까진 떠보진 않았지만, 님께서 말씀하신 S사(제 짐작이 맞다면)의 구현은 플럭인이 따로 채널을 갖고 있습니다. 그리고 전 그 S사 직원이었더랬습니다.
뭔가 님과 용어상의 혼돈이 있을지 모르겠지만, 뭐 예를 들어 서비스 자체가 문서 1-2개 보내주고 1-2개 받는 정도라면(PG처럼) 그냥 1-2개 문서에 대해서 PKCS#7으로 서명(+암호화)까지 하면 되겠지만, 인터넷 뱅킹 처럼 접속해서 웹페이지를 계속 보게되고 이의 기밀성이 요구된다면 PKCS#7 구현으로 못합니다. PKCS#7은 각 엔터티마다 RSA개인키로 서명하거나 받는 사람이 RSA개인키로 복호화해야 하는데 그 연산량이란 장난이 아니죠!
댓글 달기