タグ「署名」が付けられているエントリー

受かったから忘れていたけど，SC試験の講評がでている．秋試験以降の受験予定者は目を通しておくことを期待します．しかしながら，この講評が微妙です．

特に電子署名について，”推測した秘密鍵でメール本文を暗号化する”など，正確には理解していないと思われる解答が散見された．

平成21年度 春期 情報セキュリティスペシャリスト試験 採点講評 午後II試験（リンク先はPDF）

それはIPAがそのように説明しているからではないのか．

(2) 秘密鍵をキーとしてダイジェストを公開鍵暗号化方式で暗号化します。　→　署名データの作成

- 電子メールのセキュリティ - 3. 公開鍵暗号方式を使ってできること

2.2.3 秘密鍵による暗号化

2.2.2 においては、公開鍵で暗号化し秘密鍵で復号する方法を解説しました。これとは逆に、秘密鍵で暗号化して公開鍵で復号することもできます（図2-7）。公開鍵は誰でも取得できるため、秘密鍵で暗号を行っても 守秘性の確保にはなりませんが、秘密鍵が特定の個人のみ所有していることから、電子文書の認証と完全性の保証を実現することができます。これがデジタル署名(Digital Signature) と呼ばれる技術です。

PKI関連技術に関するコンテンツ

強調部分は私が強調しました．これはid:smoking186さんが分かりやすい解説をして下さっている．このように説明しているにもかかわらず，試験の講評では「正確には理解していない」と言われても困るどころの話ではない．そろそろこの誤解を生む解説は修正されるべきだと思うのですが，いかがでしょうか．

SSLの話がさっぱりわからない．以下，引用．

ショップは暗号化の鍵を認証局に預ける．認証局は預かった鍵を認証局の鍵で暗号化して返却．ショップは認証局で暗号化された鍵を客に渡す．客は認証局の鍵を入手，暗号を解読しショップの鍵を入手．客はショップの鍵でクレジット番号を暗号化，買い物を始める．

おかしいと思う部分を強調してみた．何週間か前に公開鍵暗号の話をやったばっかりなのに，もう忘れてしまったのか・・・．参考サイトに挙げられている総務省の説明と違うのが気になるなぁ．どっちが間違っているんだろう．わからない．

もしショップが偽物だとしたら，認証局の鍵が使えないことで見破れます．

そうなのかぁ・・・．それって，ショップが偽物というか，認証局が偽物なのでは？

その後は，SSLの認証手続きの話をしてまして，実在証明の話をしていましたが，世の中には実在証明なしのSSL証明書が山ほどあるので，SSL証明書があれば必ず実在証明がついているかのような説明では，警告が出ない正規のSSL証明書を使った悪意あるサーバに，フィッシングやらなにやらされてしまいそうで怖いです．

証明書に期限がある理由は定期的に証明書（秘密鍵）を変更することによって、悪意を持った攻撃者からの総当たり攻撃を防ぐためです。

NHK: IT whitebox

そうだったのか！証明書の中身は秘密鍵だったのか！！

まとめ：
嘘を嘘と見抜けない人がネットショップで買い物するのは難しい．もうちょっと真面目に調べて番組にするか，もっと抽象的にして誤魔化すかをした方がいいと思います．ITのブラックボックスがホワイトボックスではなく，NHKカラーボックスになってしまいますので．ちなみに，森下千里写真集は今現在で残り3冊なので，買う人は早めに．

関連：
ITホワイトボックス第3回「メールは盗み見られないのか？」 - 4403 is written
[IT whitebox]ブログ特集 - 4403 is written
SSLサーバ証明書購入奮闘記 - 4403 is written
SSL証明書の件いろいろ - 4403 is written
用途別SSLサーバ証明書を勝手にまとめ - 4403 is written

名称変更にともない、Product Advertising API にリクエストを送信いただく都度、認証のための電子署名を含めていただくことが必要になります。この変更は、2009年5月11日より3ヶ月の間の移行期 間の後、2009年8月15日には、Product Advertising API へ送信されるリクエストは全て認証されることとなり、認証されない場合、リクエストは処理されなくなります。

Amazon アソシエイト・プログラム（アフィリエイト） 公式ブログ: Amazon アソシエイト Web サービスの名称変更および署名認証についてのお知らせ

だそうです．まぁ，使ってないので関係ないですけど．REST的にはHMAC-SHAですよね．そんな理由で，WAISの発表の署名部分はHMAC-SHA256を採用していたんですけど，座長に「非対称オススメ」って言われちゃったので，うん・・・．英語力がないから言い返せない辺り，弱い．研究的な話でいけば，確かにPKI上でやるんだろうし，RSA-SHA256とかでいいかもしれない．いいかもしれなくないのは，URL長の問題だけど，これはRFC2616的には規定がない．RFCに規定がないからって制限がないわけでもないわけで，理論上は大丈夫とか，モダンブラウザでは大丈夫とか，そんな次元．個人的には携帯のブラウザでも大丈夫なように，HMAC-SHA256くらいの長さが関の山だと思うのです．RSA-SHA256は長すぎです．REST的に気分イクナイ！楕円曲線上の離散対数問題が云々だから，160bitって言えばいいのかな？簡単に実装できなさそうだから言いたくないけど．

と，今書いている論文の愚痴をこぼしても〆切が延びるわけでも，時間が増えるわけでも，執筆速度が上がるわけでも，なんでもないので，さっさと大人しく書けと，オレはオレに言いたい．

さて，タイトルと内容が不一致になっているので，HMAC-SHA256を実装する時の話をチラッと書いて，お茶を濁しておく．PHPでHMAC-SHA256する話．非常に簡単だから，良かったね．

algo

選択したアルゴリズムの名前 (すなわち "md5"、"sha256"、"haval160,4" など…)。

PHP: hash_hmac - Manual

さて，眠いので寝ると見せかけて，3章を仕上げる．

関連：
[を] アマゾンAPIを使うのに2009年8月15日から認証が必要になるらしい

200905102316追記：
PHPでこれら云々を簡単にやるPEARがあるようだ．Services_Amazonっていうらしい．便利な世の中です．なお，Perlの場合はdankogai氏作成のURI::Amazon::APAが使えるっぽい．良い世の中だ．なお，Rubyの場合はここが参考になるかと．

200905110122追記：
各言語用のまとめがありました．PHP，Perl，Ruby，Pythonがあります．Javaとか，JavaScriptとかはないですね．てか，みんなは一体なんの言語で書いているんだろう？オレなら，PHPかPerlですね．Rubyもいいなぁ・・・．

200905111052追記：
むしゃくしゃしてサンプルを書いてみた@PHP．

<?php
$key = '1234567890';
$req = array(
'AWSAccessKeyId=00000000000000000000',
'ItemId=0679722769',
'Operation=ItemLookup',
'ResponseGroup=ItemAttributes%2COffers%2CImages%2CReviews',
'Service=AWSECommerceService',
'Timestamp=2009-01-01T12%3A00%3A00Z',
'Version=2009-01-06');
$req = join('&', $req);
$message = array('GET', 'webservices.amazon.com', '/onca/xml', $req);
$message = join("\n", $message);
$hash = hash_hmac('sha256', $message, $key, 'true');
echo base64_encode($hash);
?>

ホッテントリメーカで77usersです．ちょっとメールのセキュリティについて，軽く説明してみようかと思います．ちなみに，spamメールについては一切触れる予定はありませんので，あしからず．

・パスワードを守るAPOP
メールを受信するためのプロトコルとして，POP3があります．POP3とはPost Office Protocol version 3の略でして，メールサーバからメールを取り出すためのプロトコルです．メールを取り出すプロトコルですので，誰でも彼でも使えてしまっては，自分宛のメールを他人に読まれてしまいます．そのため，メールを取り出す際の認証が必要になる．しかしながら，POP3は認証時のパスワード暗号化を提供しません．これはつまり，パスワードが平文で流れることを意味します．HTTPでいうところの，Basic認証に相当します．そのため，通信路上で盗聴が行われるとパスワードはばれてしまいます．これは結構イヤな感じです．イヤな感じですが，HTTPではBasic認証が未だに用いられていることを考えれば，大した差はないといえば無いような気がしますが・・・．

さて，そんなパスワードが平文で流れてしますPOP3の認証を安全にするプロトコルがAPOPです．APOPについては杜撰な研究者さんが書かれているので，まま引用．

APOP とはAuthenticated POP のことで、POP のようにパスワードを生でやりとりするのではなく、APOPサーバから送られたチャレンジ(乱数)に対し、ユーザはチャレンジとパスワードの連接のハッ シュ値をサーバに送り返すことで、安全なパスワード認証を実現しています（ただしメイル本文は平文のままです）。

杜撰な研究者の日記: APOP

ここで説明されているとおりです．つまり，HTTPでいうところのDigest認証に相当します． APOPによって，パスワードが平文で流れることがなくなることはお分かり頂けると思います．これで安心！ではないんです．昔はこれで安全だったんですが，APOPに用いられているハッシュ関数であるMD5の危殆化によってパスワードが復元されるという攻撃を受けてしまいます．このAPOP上におけるMD5コリジョン攻撃はLeurentやSasakiらによって，ほぼ同時期に行われているという話も，杜撰な研究者さんが詳しくされているので，繰り返しません．この問題に対して，2007年の話になりますが，IPAは以下のような注意喚起を行っています．

独立行政法人 情報処理推進機構（略称：IPA、理事長：藤原武平太）は、メールの受信に利用される認証方式の一つであるAPOP（エーポップ）方式におけるセキュリティ上の弱点（脆弱性）に関する注意喚起を2007年4月19日に公表しました。

（中略）

プロトコル(通信手順)上の問題であり、現時点で根本的な対策方法はありません。

回避方法は「『POP over SSL』や『ウェブメール』など、SSLによる暗号化通信を利用する」ことです。回避方法が取れない場合「メールのパスワードを他のシステムのパスワードと同一にしない」ことで悪用された際の被害を軽減できます。

情報処理推進機構：情報セキュリティ：脆弱性関連情報取扱い：APOP方式におけるセキュリティ上の弱点（脆弱性）の注意喚起について

ということで，APOPはパスワードを通信路上に平文で流すことなく認証が可能なプロトコルですが，ハッシュ関数の危殆化によって，その安全性に問題が発生したのでした．

・通信路ごと暗号化してしまえPOP over SSL
そこで，次の話です．IPAでも回避方法としてあげている，over SSLです．これは簡単で，POPをSSL化してしまえ，えいや！というものです．これをPOP over SSLといいます．POPSと呼ばれることもありますが，一般的かどうか・・・．これはHTTPでいうところのHTTPSに相当します．これは最早，SSLで通信路が暗号化されますので，パスワードが平文で流れる云々もなにも，メール本文すらも暗号化されて通信路を流れます．当然，SSLの安全性に依存します．POP3やAPOPに比べて，POP over SSLが如何に安全になるかは，@ITの表がわかりやすいと思います．これで，通信路上での盗聴の問題は解決しました．

とは問屋が卸さない．やはり同様にして，MD5コリジョン攻撃の問題がやってきました．先日書いた，MD5なSSL証明書の問題です．SSL証明書の問題は残りますが，これは別に，POP over SSLに特化した話ではなく，SSL全般の話なので，詳しくは触れません．そういうことがあるという話だけ．

ちなみに，IPAの回避方法でも述べられていますが，案外Webメールは安全です．通信路がSSLで暗号化されている的な意味で．GmailならHTTPSで接続されると思います．注意しないとHTTPで通信してたりするけど．素のPOP3やAPOPを使うくらいなら，HTTPSなWebメールの方がいいかもしれません．HotmailとYahooメールはSSLにならないなぁ・・・．優しくないなぁ・・・．

・こうしてメールのセキュリティは確保されました？
これで，クライアント－サーバ間の通信路の安全性は守れられました．パスワードも安全そうです．良かった良かった．で終わらないから，このエントリを書いているんです．では，どこがダメなのでしょうか？クライアント－サーバ間が安全になったにも関わらず・・・．

そうです．サーバ－サーバ間の通信が安全ではありません．もっと言えば，サーバが安全ではないかもしれません．そうです．APOPでパスワードの安全性は確保されますが，メール本文の暗号化はされません．POP over SSLは通信路上において，メール本文も暗号化されていますが，メールサーバ上では暗号化されていません．これは何を意味するかと言えば，サーバ－サーバ間の通信においては，メール本文が平文で流れていること，そして中継に利用されたメールサーバはメール本文を平文で見ているという点です．厳密には，普通のテキストが流れているわけではなく，BASE64などのエンコードがかかった状態で流れていますが，符号化は暗号化ではないので，平文と考えて問題がありません．

つまり，メール本文は暗号化しない限り，平文で流れます．メール本文は暗号化しない限り，平文で流れます．重要なことなので，2回書きました．

・メールを暗号化するPGPとS/MIME
メール本文を暗号化しない限り，安全にならないのであれば，暗号化すれば良いんだ．簡単なことです．そのソリューションを提供するのが，PGPとS/MIMEです．PGPはPretty Good Privacyの略で，公開鍵暗号方式を用いていますが，Web of Trustと呼ばれる仕組みによって，信頼を得る方式になっています．対して，S/MIMEはSecure/MIMEの略で，公開鍵基盤（PKI）アプリケーションです．この2つの方式の大きな差は，公開鍵の信頼性をどのように保証（確認）するかという違いです．この2方式の差も，今回書きたいこととは直接関係がないので，詳解は避けます．

結論だけ言いますと，PGPやS/MIMEを利用することで，メールを暗号化することができます．それだけではなく，ディジタル署名を付けることもできます．これによって，盗聴の脅威を防ぐだけではなく，メール本文の改ざんを防ぐこともできますし，送信者の否認を防止することができます．こうして，メールは安全になりました．

はて？あなたは今までに1度でも，PGPやS/MIMEによって暗号化されたメールを受け取ったことがありますか？無いのではないでしょうか．ボクは学生時代に「試して見たがり衝動」で，PGP暗号化/署名を試しています．S/MIMEも第四種オレオレで良ければ，院生時代に試しています．でも，それだけです．「試してみた」レベルです．何故，このようなセキュリティソリューションが利用されないのでしょうか？300字以内で答えなさい（配点：70）．

ちなみに，電子メールに署名を付ける人は少なからずいます．これはメール送信者のセキュリティ意識の高さを示していると言えるでしょう．しかしながら，何故かそのような人においても，暗号化されたメールは送ってきません．何故なのでしょうか？200字以内で答えなさい（配点：30）．

ちなみに，MUFGのメールにはS/MIMEの署名がついています．Gmail S/MIMEというFx用のアドオンを導入すると，簡易的ながらGmail上で署名を検証できます．

まとめ：
POP3ではパスワードが平文で流れます．APOPはそれを防ぎますが，安全ではなくなりました．POP over SSLはクライアント－サーバ間の通信をSSLによって暗号化するので，安全です．しかしながら，クライアント－サーバ間以外の通信に保証がないので，暗号化されていないメールは中継中に盗聴可能です．そのため，PGPやS/MIMEでメールを暗号化すると良いです．

何が書きたかったかっていうと，2点です．内部ではPOP3でメールが運用されています．外部からはVPN接続しないとダメなので，このネットワーク構成は安全です．っていうのは，安全ではありません．敵は外からのみ来るのではなく，内部にも存在し得ます．逆内弁慶はセキュリティ上，安全ではありません．

もう1点はGmailを否応なしに毛嫌いする人です．Googleは個人情報を集めまくっている．きっとメールも覗かれているに違いない．その証拠にメールの内容に合った広告が出るじゃないか！という主張．これ自体はその通りでしょうが，だったら平文でメールを流さないで下さいといいたい．Gmailを使わないとしても，中継サーバがメールの中身を見ていないとは限らない．Gmailだからというのはリスクの差を生みません．

意見交換会を開催させて頂きました．外部から優れた研究者様2名をお招きして，一方的に情報を頂いたばっかりの様な意見交換会でした．大変お勉強になりました．お暑い中，わざわざお越し頂きまして，誠にありがとうございました．ならびに，意見交換会といいつつも，意見が交換されたのは酔ってからといううｗ（げふんげふん．申し訳ありませんm(__)m．私も発表することは全く問題はなかったのですが，「研究室の」を優先したときに，私の優先度は幾分低くなるので・・・．次回は必ず準備させて頂きますm(__)m．

既にご存じかと思いますが，備忘録．CSEC研究会にCSS2008のCFPがでています．今年は沖縄ですよ！AINAで行き逃した沖縄ですよ！

平成20年10月8日（水）～10月10日（金）
於：沖縄コンベンションセンター（宜野湾市）
論文発表申込締切（アブストラクト）：平成20年08月08日（金）
最終原稿締切（カメラレディ） ：平成20年08月25日（月）
CSS2008ホームページ

・・・・・・．授業休めるかな・・・．後期が始まってすぐって，厳しいなぁ．しかも，投稿時期も厳しいなぁ．そうやって参加者を絞り込むんですね．わかります．会場はコンベンションセンターって，AINA2008と全く一緒で，完全に行き逃した沖縄．

みんながんばろう！

勉強させてください．SCIS2008で発表されたUKのδ方式についてです．δの決定方法が分かりません．GoogleDocsを利用して説明します．どなた様か，御教示下さい．

根本的に激しく間違っていたり，単なる知識不足で恥をかきそうなときは，即行でエントリーごとなかったことにしますので，そういうご連絡もお願いします．よろしくお願いいたします．

uk.javaをダウンロード（mod φ(n)適用しました200802150055）

200802150055追記
mod φ(n)にしました．でも，上手くいかないところがあります．どこが間違ってますか＞＜数学的な証明は不勉強のために，通じない可能性が高いですが．

更新履歴：
初版：200802112306
第2版：200802150055

SCIS2008の3F4-2にて，CSS2007の6B-3で発表されたUK1および改良されたUK2の更なる改良として，DA方式とδ方式が提案された．また，3F4セッションでは3F4-3として，UK1およびUK2に対する攻撃方法と安全性の考察が行われている．多くの方々に注目されているようで，セッション内外で色々と議論されていた模様です．

そもそも，何故こんなに注目されているのか．研究内容が興味深いとか，そういう真面目なアプローチは専門外でなんともかんともなので，別のアプローチから分析してみる．

まず，このUKが公表されたのは，CSS2007の6B-3である．しかし，UKはCSS2007会期中のキャンドルスターセッションにおいて，攻撃を受けている．6Bセッションは2日目であるが，キャンドルスターセッションは1日目である．不思議なことに，公表前に攻撃されるという，-1DAY ATTACKを受けてしまったのだ．

どうやって公表前に攻撃ができるほどの詳細情報を知り得たのか．これは簡単なことで，UKのKが漏らしたらしい．その時のやり取りが-1DAY ATTACKに結びついたようですが，オレが書いていいことではなさそうなので，割愛．要するに，Kと攻撃者が結託しなければ，この攻撃は成立しなかったものと思われる．

が．だ．実はもっと早い段階で情報が漏洩していた事実に，気が付いた．そもそも，UKのUはM2であり，修論発表を控えており，9月頃には修論中間発表会が執り行われた．そして，修論中間発表会の情報を学外に漏洩させる人物が存在し得たのだ．攻撃者はその漏洩元から情報を得て，Kから情報を入手するに至ったようである．では，その最初の漏洩元は一体誰か．

それ，なんて，オレ．

というわけで，UKが攻撃されまくりんぐで人気ありまくりんぐなのは，オレのお陰という方向で．宣伝効果抜群ですねっ！Uにとっては災難だったかもしれないけど，研究って概ねそんなもんでしょ．

なお，SCIS2008終了間際に杜撰な研究者さんとお話ししたのですが，新型UKに対する攻撃の提案が早くも数件あったようです．しかも，かなり根幹的な部分に対する攻撃という未確認情報．オレには確認のしようもないけど＞＜．修論発表会まで頑張れ！