Financial Cryptography에서는 Microsoft, AOL, Mozilla 등 브라우저의 anti-phishing 정책을 비판하면서 이런 접근은 대안이 될 수 없다고 합니다.
브라우저 업체의 정책을 살펴보면 "피싱으로 의심이 되는 사이트 리스트"를 브라우저가 감지할 수 있도록 한다는 것입니다. 해당 Blacklist는 phish report network을 통해서 유지되며, 이 네트웍은 WholeSecurity라는 회사가 관리합니다.
Phish report Network은 MS, eBay, Visa가 후원하네요...
바이러스, 스파이웨어, 피싱...!?
Technorati tag : 피싱
신용카드 청구서 등 사적인 내용의 피드를 어떻게 안전하게 전달할 수 있을까요?
Joe Gregorio 씨는 Greasemonkey를 통한 RSS 암호화를 제안합니다.
Gregorio씨는 피드를 패스워드로 막는 것은 aggregator에게 패스워드를 알려줘야 하기 때문에 안되고, Atom Spec에서 제안한 XML Encryption의 경우에도 Atom Spec이 완료되지 않았고,
aggregator들이 XML encryption을 지원하지 않기 때문에 안된다고 하면서, Greasemonkey를 사용한 RSS 암호화를 제안합니다.
구체적인 시나리오는 다음과 같습니다.
This is a Blowfish encrypted message.
The unencrypted content in this div should remain unchanged.
암호화하기 전에 피드 데이터는 다음과 같습니다.
WORK:C7FDDC3B50FF0BE0E6F47CBD54AC149FA6E42F1D-D9C8AEA48F4D400B6970C14082858FF94901795DBE1C7D3-80ED6AA16A1B2F8039C6782D604F1CA906A6F1C7CFEB52-DED873A557228333D3A6E8B3712BD115C4AC0643B86
The unencrypted content in this div should remain unchanged.
이제 신용카드, 각종 영수증을 E-mail말고 RSS로 받아볼 수도 있지 않을까요?
(근데, IE7은 이런 기능을 지원할 수 있을까요?)
Technorati tag : Secure RSS
28일-29일 주민번호 대체수단 정책 워크샵이 개최되었습니다.
소시모에서 주민번호 대체 수단 마련을 위한 여론 조사를 했는데요,
재미있는 결과 몇 가지를 소개하면,
PC통신 시절 코스닥 열풍을 불러왔던 새롬기술을 기억하십니까?
새롬기술의 창업주역들인 조원규(Ted Cho), 최진권, 김도연, 김홍철씨가 Opinity라는 회사를 차렸네요. 자신의 온라인 평판을 관리하는 서비스입니다.
전자상거래 등 온라인 사업의 활성화와 평판이라는 것은 맞닿아 있다고 생각하고 있었는데요...
이 회사 잘 지켜봐야겠네요... 등록해서, 반갑다는 인사도 전하고^^
피싱이나 Pharming 공격의 출현은 대부분의 사람들이 보안에 민감하지 않음을 간접적으로 표현하는 것이라고 생각합니다. 이런 공격법의 출현은 반대로 보안을 하는 사람들이 어떻게 보안시스템을 설계하고 효과적으로 "안전함과 안전하지 못함"을 표현해야 하는 지를 모른다는 증거도 되겠지요...
이런 측면에서 Usable Security는 너무나도 배울 것이 많은 사이트라고 생각합니다. 보안을 하는 사람이라면 꼭 구독해야할 블로그가 아닐런지요?
중국에서 Paypal 서비스를 시작한다고 합니다. 그런데, 기사를 읽으면서 새로운 사실을 알게되었는데요, 중국에서의 경매 사이트는 B2B 경매를 주로하는 회사인 Alibaba가 먼저 시작했고(taobao.com) 지불서비스 또한 Alipay란 브랜드로 먼저 시작했다는 사실입니다.
그런데, 경매 사이트는 왜 항상 지불서비스를 같이 가져가려고 할까요?
인터넷뱅킹이 또 뚫렸다고 합니다. 이번에 사용된 기법(?)을 살펴보면,
VISA는 PCI(Payment Card Industry) 보안 표준을 만들었으나, 카드시스템사가 보안 표준을 무시했기 때문에 사고가 났다고 합니다. 글 중간 쯤에 Shneier씨의 말을 인용하면,
PCI 표준이 표준을 준수하지 않은 기업들에게 벌금을 부과하여 신용 카드 처리 비용을 상승시키기 때문에 저항이 있지만 비자와 마스터카드가 이 문제를 해결해야 한다고 말했다.생각해보면, VISA는 보안표준을 만들고 이를 지키지 않으면 카드사고의 손실을 벌금이라는 형태로 신용카드 처리 대행사(VAN사)에게 부과하는 것인 데...
올 2월에 중국의 학자들이 SHA-1을 깼다고 해서 시끄러웠는데요, 전자서명에 영향이 있느냐 없느냐 등등...
일방향 해쉬 함수는 입력의 길이에는 상관없이 20바이트의 결과값을 내고, 또한 결과값을 안다고 해서 입력값을 역으로 계산하는 것은 불가능한 함수를 말합니다. 보통 원문에 전자서명을 할 때, 해쉬 함수를 통해 원문에 대한 20바이트 해쉬값을 구하고 이 해쉬값에 전자서명을 하게 됩니다.
그런데, 만약 서로 다른 원문이 같은 해쉬값을 가진다면 어떻게 될까요? 가령, 인터넷 뱅킹에 계좌이체 시에 공인인증서로 전자서명을 하는 데, 해커가 해쉬값은 같지만 이체금액은 다른 전문으로 교체가 가능하다는 얘기가 되는 것이지요...
심각하지요?
아뭏든 소문만 무성하던 그 사건에 대한 정식 논문이 온라인에 배포되었습니다.
실제로 위와 같이 조작이 쉬워지는 것인 지, 본 논문이 미칠 영향에 대해서 암호전문가에게 물어봐야겠네요...
지윤님께서 웹 포털 사이트들의 개인정보 보호수준에 대해서 언급해주셨습니다.
글 내용 중에 구글은 "최소한의 정보만을 수집하고, 개인정보보호 정책에 쉽게 접근하도록 했다"라는 부분을 언급하셨는데요.
이는 Identity 제 2법칙, 최소 공개의 법칙에 해당하는 내용이네요.
이 글을 읽게 되시는 분들은 다른 Identity 법칙들도 살펴보시는 것이 개인정보보호를 잘하는 웹 사이트가 되는 길이라고 생각합니다.
참고로, 미국에서 성인인증 관련 법을 강화하고 있다고 합니다. 국내에서 주민번호 보호, 결제 시 부모 동의 등의 인증 절차를 강화하려는 움직임과 일맥상통한다고 생각합니다.
현재 메일을 보내는 도메인의 50% 가량이 SIDF와 Signature를 통해서 outbound 메일을 인증하고 있다고 합니다. 자신의 DNS 레코드를 고쳐서 보내는 메일 서버의 주소들을 명기하자는 것이 주요 아이디어인데요, 이제 머지 않아 스팸 메일도 없어질려나요?
SIDF에 대해서 잘 모르시면 이 발표자료를 참고하세요.
MBC 2580 인터넷 뱅킹 사고의 시작은 다름아닌 백오리피스를 설치하는 피싱메일이었는데요, SIDF를 적극적으로 검토해보시고 DNS도 수정해보는 건 어떨까요?
인터넷 뱅킹이 처음으로 해킹을 당했다고 합니다. 동아경제의 기사를 조금 인용해보면
어떻게 빼냈나=‘넷 데블’ 프로그램의 특징은 해커가 지정한 글이나 그림을 클릭하면 자신의 컴퓨터에 자동으로 깔린다는 점.위의 사례는 Two-factor 인증은 안전하지 않다에 서 소개한 바 있듯이 Trojan horses를 고려하지 않았기 때문에 발생한 문제이며, 같은 글에서 언급했던 것처럼 진짜 문제는 "사칭에 따른 공격"입니다. 보안이 강화된 Two-factor 인증 방법으로써 대응하지 말고 어떻게 하면 "사칭에 따른 공격"을 막을 것인 가에 대한 고민을 해야 합니다.
이용자는 자신의 컴퓨터에 프로그램이 깔리는지를 전혀 알 수 없지만 해커는 상대방이 컴퓨터 자판에 입력하는 내용을 자신의 컴퓨터를 통해 실시간으로 볼 수 있다. 상대방이 어떤 화면을 보는지도 파악이 가능하다.
이 씨는 이런 ‘키 스트로크(key stroke)’ 방식으로 피해자의 거래은행과 계좌번호, ID, 비밀번호, 공인인증서 비밀번호, 보안카드번호를 모두 알아냈다.
전문적인 해커가 아니라 하더라도 이 프로그램을 이용하면 상대방의 개인정보를 빼내는 일이 그다지 어렵지 않다는 것. 이 씨는 4월 자신의 계좌를 이용해 예행연습을 한 뒤 바로 실행에 옮겼다.
특히 현재의 전자금융거래 약관에는 이런 경우에 고객이 책임을 지도록 돼 있는 것도 문제입니다.고객의 잘못이 없는 경우, 금융기관이 책임을 져야 하는 법안이 국회에 제출된 상태지만 금융권의 반발로 처리는 미지수입니다.
피싱과 ID 도용이란 글에서 소개드린 것처럼, 이 사건의 책임은 전적으로 은행에 있습니다. 왜냐하면 은행이 거래를 허가했기 때문입니다.
은행은 "거래를 인증해라. 사람이 아니고"란 말을 명심하고, 피싱과 ID 도용에서 언급한 권고사항들을 시스템에 반영했어야 합니다. 다시 한 번 적어보면,
LID의 제안자인 Johannes Ernst는, Julian Bond씨가 "MS의 Infocard는 첫번째 장벽을 넘지 못할 것이다"라고 한 의견을 소개하고 있습니다. Julian Bond씨의 의견을 조금 살펴보면,
Infocard는 Apple과 Linux 클라이언트를 고려하지 않았다. 그리고 아마 firefox와 다른 브라우저들을 고려하지 않았을 것이다. 그리고 거의 틀림없이 PHP-Apache 사이트를 고려하지 않았을 것이고, Java/Perl 서버는 WS stack에 있어서 MS와 호환되지 않을 것이다.
따라서 시장의 50% 이상은 제외된다. 중소형 규모 웹 사이트들의 longtail을 포함하여...
Bank of America가 Passmark Security 사의 기술을 사용하여 sitekey라는 two-factor 인증 서비스를 제공한다는군요.
Passmark Security 사의 기술은 간단하게 말하면,
자신만이 아는 이미지를 접속할 서버에 등록해놓고 이 이미지를 보여주는 사이트에만 패스워드를 입력함으로써 피싱을 막을 수 있다는 것입니다.
해당되는 이미지의 선택과 패스워드 입력을 동시에 해야하므로 two-factor라는 얘기인데요...
가짜 상점을 만들고 여기에 사진을 등록하게 한다면, 대부분의 사람들은 같은 이미지를 등록할 것 같고, 그렇게 되면 마찬가지로 피싱 공격에 노출되는 것 아닌가? 하는 의문이 듭니다.
마이크로소프트의 신규 Identity 프로젝트인 Infocard에 대한 Whitepaper가 나왔습니다.
Infocard에 대한 기본 개념을 파악하기 위해 whitepaper 중에 일부를 번역해보면,
오 프라인에서, 사람들은 지갑 안에 여러 가지 형태의 identification, 운전면허증 또는 주민등록증, 신용카드, 멤버쉽카드 등등, 을 가지고 있다. 자신이 어떤 카드를 사용할 지 그리고 주어진 상황에서 얼마만큼 많은 정보를 공개할 것인 지를 결정한다.
유 사하게, identity metasystem은 사용자들이 인터넷의 자원들을 안전하게 유지하고 제어하기 쉽게 만든다. metasystem은 사용자들이 이용하고자 하는 인터넷 서비스에 따라 digital identity를 선택할 수 있도록 한다.
...
Digital ID World 2005의 Presentation과 Audio가 게시되었습니다.
Kim cameron씨의 Identity Laws와 얼마전에 소개한 Identity Gang panel도 눈에 띄네요...
Schneier씨는 한 에세이를 소개하면서, 다음과 같은 문구를 인용합니다.
아이디와 비밀번호로 로그인하는 은행이 있다고 하자. 당신은 아이디와 비밀번호가 노출되지 않도록 조심해야 한다, 이게 맞을까요? 아닙니다! 조심해야 할 것은 누군가가 돈을 훔쳐가는 것입니다. 두 가지 시각을 구분하는 것은 매우 중요하다. 만약 계좌에 돈이 없고, 사용하지 않는다면 누군가에게 아이디/비밀번호가 노출된다고 해도 아무런 상관이 없다. 아이디와 비밀번호는 은행이 그것을 아는 사람에게 돈을 인출해주는 경우에 한해서만 가치가 있다. 여기에 진짜 문제가 있다. 은행은 Schneier씨가 "거래를 인증해라, 사람이 아니고"라고 언급한 것을 실행하기에는 너무 게으르거나 무능하다. 누군가가 접근권한을 훔치는 것을 막는 것은 굉장히 어렵운 반면, 외국으로부터 돈이 인출되는 것을 막는 것이 훨씬 쉽다.에세이는 구체적으로 다음과 같은 권고를 하고 있습니다.
사고가 나면, 은행은 당신이 거래를 "인가했다"라고 말할 것이다, 여기서 궁극적으로 거래를 "인가한" 것은 은행이다.
Personal Digital Identity의 움직임을 주도하고 있는 ID 관리 전문가들이 한 자리에 모였네요...
Kim cameron 씨가 Infocard에 대해서 간단한 소개를 했다고 하고, 곧 코드가 나올 것이라고 합니다.
Infocard의 Windows part의 이름은 "Identity Selector"라고 하네요...
기대됩니다. Identity selector 코드가 공개되면, 제가 하고 있는 프로젝트와 연계할 수 있는 방안을 찾아봐야겠네요...
