DelphiでHMAC-SHA256 (aws電子署名用)

　気が向いたところで、簡単関数も実装してみました。基本的に、aws用のユニットなので、簡単関数だけを使う前提のunitです。
　電子署名の無いURL(RESTのQuery含む)と、署名に必要な鍵(Secret Access key)を渡すと、パラメータのソートと、URLエンコードと、タイムスタンプ(Timestamp)の付加と、署名をつけたURLを返します。あとはこれでサーバをたたくだけ。
　あえて、コンポーネントとかではなく、単なるunit(*.pas)にしているので、コンポーネントの追加ができないTurbo Delphiでも、たぶん、動きます。

関連リンク
・Amazon Web Serviceの電子署名支援

sha256とlazarus(というか、Delphi)

　Amazon Web ServiceでSHA-HMACによる電子署名が必要になるとゆー話がでて、いまのところ、変更とかの話はでてないようなので、そろそろ、「あれ？これって、じつはないんじゃぁ？」など、いろいろとあったり、なかったりしますが。
　電子署名に使用されているSHA256とHMAC、電子署名としては有名なので、電子メールやSOAPなどのライブラリにまぎれているかも知れません。が、SHA256という方式自体は、md4の後継のmd5の後継のSHA1の後継に出てきたものなので、ちょっと古いとmd5、当時の最新でSHA1までとゆー可能性がちまっとあったりします。
　そこで、そのむかしフリーでダウンロードできた、Delphiの古いバージョンやら、Turbo Delphiやれでも、つかえるとよいなぁ　ということで、MarleySoftさんのところの、MD5のソースを参考にして、Lazarusで(いちおDelphi互換。)SHA256と、SHA256-HMACを実装してみました。てきとーに組み込んで使ってよい・・・ような気がします(⇒これ。必要なのはawsassist.pasのみ。)
　なお、Unitのinteferfaceには、CalcSHA256(結果は16進表記文字列)とCalcSHA256HM(Base64文字列)の２つですが、内部で実装されている関数をうまく利用して実装すると、秘密鍵そのものをソースに埋め込まなくてもよくなります。ヒントは、以下の関数(と、過去の記事)。

SHA256HMInit(context,dummySrc,0);
SHA256HMSetCryptKey(context,Key1);
SHA256HMUpdate(context,ASrc,ASize);
SHA256HMSetCryptKey(context,Key2);
Result:=SHA256HMFinal(context);

気が向いたら、ちゃんと実装します。

グインサーガ 未完。

　@niftyのニュース記事を見て知りました。
　まだまだ、若いのに、残念なことです。私はグインサーガしか知りませんでしたが、記事を読むと、結構多芸な方だったんですね・・・

awsと認証とJavaScript

　別の記事に書いてあるSignatureの先行計算を行う場合、method(GET),host,URI,アルファベット順のパラメータのうち、固定でよいところまでしか適用できない。おそらく先頭の方に来ると思われるパラメータに、AWSAccessKeyとAssociateTagとがあるため、AssociateTagを書き換えての盗用は防げる。が、単に何でも良いから配置したいだけ　というのは防げない。
　AssociateTagが固定できることと、鍵を埋め込まなくて良くなるという点を利用し、「鍵の解析が困難なその人専用のJavaScriptソースを提供する」というサービス(商売)が成り立つかもしれない。問題は、「ソースを生成するのは、鍵が必要」という点と、「鍵は第３者に知らせては行かない」という点。このため、鍵を聞いてソースを生成して提供する・・・という手段が使えない。JavaScriptソースを生成するクライアントプログラムの提供を形を取り、実行には「アクセスキー」「アクセスキーに対応する専用パスワード」(※)を入力する必要がある　とすることで、可能かもしれない。まぁ、最大の問題は、そんな魅力的なJavaScriptを知らない(持って無い)　とゆー点ですが。むむ、この販売モデル自体を販売するというのは手かもしれない(笑)

一応、この仕組みを使った場合の制限。
・AWSAccessKeyとAssociateTagよりも前にくるパラメータを使用できない(少なくとも変更可能にはできない)
・Requetの発行そのものの盗用を防止する方法ではない。
・shaとhm-shaの仕組みと、それを利用しているという点を知っていれば、自力でどーにでもできてしまう。
　（まぁ、もともと自力でどーにもでもできるひとは、こんな機能なくてもどーにでもなりますからね)

※ 単純には、アクセスキーhash値とか(単純だとばれちゃうので、実際はひねらないとだめですが)

Amazonの新APIでのSHA-HM用のキー(極秘鍵)を安全に設定する方法を考えてみる

タイトルに在るように、Amazonの新APIでのRequestへの電子署名時に使用するSHA-HM用のキー(極秘鍵)を安全に設定する方法を考えてみることに。

エンドユーザの環境で実行されるスクリプト言語の場合、安全に利用可能と思われる方法は無い。これは、「加工すると署名に利用できる値」「その値を署名として利用する為のロジックソース」が、見えてしまう為。
# Javaは、コンパイルしてバイナリでの配布となるものの、逆コンパイルも容易であることに注意。Flashや.NET上で動作するアプリケーションも同様の注意が必要な可能性あり。

エンドユーザの環境で実行されるバイナリアプリケーションである場合、解析をより複雑に(手間をかけさせる)ことは可能であるが、解析不可能にする方法はない。
・アプリケーションに埋め込む際に可逆な暗号化を施す。実行ファイルをdumpしただけで判る・・・というのは避ける。
・一般的な/標準的なSHA-HMライブラリを使用しない。ライブラリの呼び出しポイントをhookされるのを避ける(WindowsのDLLなど、動的リンクされるものは特に注意)
・sha-hmの演算の途中の値を保持し、鍵には戻さない(sha-hmの処理自体を、その途中の値から継続して処理可能なロジックに作り変える必要あり(※2))
どちらにしても、requestに署名を行う為には、もともとの鍵に戻す必要がある(※1)。そのため、「いかに、戻ったタイミングを知られないか」ということを注意するしかない。
※1 鍵が使用するsha-hmの１ブロックよりも長ければ、最初に１度、shaがかかるので不可逆になるが、今回は該当しない。
なお、鍵そのものが必要ない(たとえば、不可逆なハッシュ値が使えるとか)というように変更されたとしても、任意のrequestの文字列に正しく署名するための値を持つには変わりないので、なんらかの、「盗用すると、勝手に署名できる値」を含む必要があり、結果として、(鍵の値はばれてないけど偽装はされるという)あまり、鍵の秘密性を上げた意味がない結果になるような気がする。
# 鍵の値が他のことにも使えれば、値そのものがばれないことに意味があるんですが、署名で使う以外になにもないような？

上記２つについて、(1)APIへのリクエストそのもの、もしくは、(2)リクエストに署名をする部分のみについて、サーバサイドで実行するという手も考えられる。(2)の欠点は余分なサーバへの通信が発生すること。(1)と(2)の共通の欠点として、このサーバでの署名処理がネックになる可能性があることと、この処理とこれに依頼してくる処理の間の認証をしっかりしないと、このサーバでの処理自体が悪用される可能性があるということ(だれからの要求でも、自身の署名をつけてしまったら、大問題。が、署名サービス(requestの文字列を送ると、署名したrequestの文字列が得られる)とか善意で作っちゃう人が出てくる可能性も０ではないかも。)

※2 以下のタイミングの値を利用できるかも(名称は、shaおよびhmacの仕様を参照)
１．key0
　(この値は鍵を逆算可能)
２．以下の２つ(可逆なのでkey0^ipdaの値から、key0^idap^ipad^opadとしてもう一方を求めることも可能。)
　key0^ipad
　key0^opad
　(この値は(どちらの値からでも)鍵を逆算可能)
３．以下の２つ
　key0^ipadをsha256で処理した１ブロック目としてのa～h相当
　key0^opadをsha256で処理した１ブロック目としてのa～h相当
　(実質、keyを１ブロックとしてshaしたのと大差ない。不可逆)
４．「３．」の値＋α
　続くブロックについて、可能な限り予め演算してその途中となる値を持つころで、そこまでの文字列を改変不能とすることが可能。ただし、常に先頭からしか適用できない。

「３．」もしくは「４．」の値を、他の２案(可逆に暗号化する、ライブラリなど区切りの判る呼び出しをしない)を混ぜることで、かなり解読は困難となりそう。おそらく、ここが限界・・・・か？
　この方法であれば、JavaScriptに埋め込んでも、鍵の値そのものは求めることが出来ないようにすることは可能。ただし、「requestを発行できるソース」という点には変わりないので、鍵の値そのものがばれていないだけで、署名自体は盗用される状態になってしまうため、意味は薄い(利用規約への言い訳以外の目的は思いつかない)。なにか、もうひとひねりしてJavaScriptから安全に利用可能だったりすると良いんですが・・・いまのところ思いつきません。

余談。
　2009/05/21現在では、Request中のTimestampのパラメータについて、未来側での上限制限がかかっていないっぽい。そのため、呼び出すサービスの内容(requestの文字列)が完全に固定でよいのであれば、未来のTimestampにてrequestを生成し予め署名をしておくことで、固定リンクからawsを利用することは可能。このこの場合、リンクに含まれる値(署名対照の文字列と生成されたSignature)から鍵を求めることはできず、また書き換えたrequestに用いられてしまうことも無い為、安全ではある。

Amazon Web Service(aws)のAPI変更とか

　各所で話題になっている、AWSのAPIの変更。パラメータにタイムスタンプとシグネチャ(秘密鍵による電子署名)が必須となるという。いまのところ、執行猶予期間中でパラメータは省略可能。このアナウンスが５月で８月には必須化のよーです。
　この変更により、javascript等のユーザにソースを提供する必要がある言語により作成したawsを利用するプログラムを作成して配布(販売)していたサイトは全滅です。静的リンクやajaxでなんか作っていた人も全滅です。おそらくは、まさに、そのタイプのプログラム(で、同一アクセスキーがやたら配布されている)からのアクセスを禁止するための変更なんじゃないか　と思わなくも無いですが。基本的に、awsを利用しているプログラムを販売していたところは、全滅に近いと思われ(大丈夫なのはプログラム本体を提供しないリンク埋め込み型ぐらい?)

　そして、当方でも、以前、phpによる月単位の検索を行うプログラムを作っていたわけなんですが・・・がんばって、電子署名に対応しました。電子署名の部分は、phpのマニュアルのコメントに投稿されていたLGPLライセンスのsha1のソース(phpのソースではないです。phpで書かれたプログラムです。念のため)をもとに、sha256,sha384,sha512を実装し、さらに、sha1とsha256のHMACを実装したものを使っています(ベースがLGPLなので、作成したSHA処理もLGPL。独自に実装したので古いphpでも動くかも)
　今回の変更で、「これもってかえって自サイトで使おう」と思う場合には、自身でawsのアカウントを取ることが必須になります。以前は、念のためソースに埋め込んであるawsアクセス用のキーを利用して動作したんですが、秘密鍵は配布できないので、８月以降動きません(もちろん、以前のバージョンのままだと電子署名に対応して無いので８月以降は動きません)
# 秘密鍵が空欄であれば、以前と同じ動作しまふので、８月まではうごきまふ。

関連リソース
・１ヶ月のアマゾンの書籍を一定条件で検索

プリンタ購入

PrintableなCD/DVDラベルに印刷する為、対応のプリンター(複合機?)を購入しました。
# いや、なにか、Linuxのインストールを試みようとするたびに毎回メディアを焼くのは無駄だなぁ　と。

しかし、最近のプリンターには、有線LANだけではなく、無線LANも付いているのには驚きました・・・
そして、CDラベルのコピーが出来るのも驚いた・・・
# そして、パラレルポートが無いのがちょっとさびしい・・・

カスペルスキーで誤定義ファイルの配布による障害発生・・・・らしい(CNET-JP)

　記事によると、4/2の早朝から16時ごろまでに配布されていた定義ファイルに問題があり、この定義ファイルを取り込むとAntiSpam機能が無効になってしまうそーです。で、それだけならたいしたこと無い(いや、あるか)のですが、以下のような状態に落ちいる可能性がありえるそーです。
・もともとAntiSpamを有効にしていた。
・誤定義ファイルでAntiSpamが無効になる。
・AntiSpam機能が無効になっているという警告Popupがでる。
・警告Popupの指示に従いAntiSpamを有効にする操作をする(これが厳禁だそーです)
・挙動がおかしくなり、カスペルスキーのアンインストール/インストールをしない直らない。

該当しちゃっているかもしれない人は、AntiSpamの設定をいじる前に、とりあえず、定義ファイルを更新してみることをお勧めします。

　うーむ、こういった障害で再インストールを余儀なくされたら、他のソフトに切り替えちゃう(か、Virus対策ソフトの利用をやめてしまう)ような気がするのは気のせい？
　なにか、ほかの有名どころでもたまに致命的な障害をやらかしてますが、ほかに比べて、多いような気がしますが、実際はどんなもんなんでしょうか。
# 無名なものはニュースにならない為、把握できないので、障害が少ないような気がしてもあまり当てにはならないんですが。

関連ニュース
・カスペルスキー製品のアンチスパム機能に不具合、新しい定義ファイルに更新を

まんがタイムスペシャル５月号

　新たな感じの、「ふたご最前線」や、収束に向かう「それだけでうれしい」なども良い感じですが、それらをおいといて、１番わらったのは、葉っぱの歌でした・・・

　ところでふと、「それだけでうれしい」の最後のこま、かっこよいせりふだなぁ　と思ったわけなんですが、なにか、こう、以前にも(違う方向で)似たようなもので、心に奥底に残っているようなものがあるような・・・・と、しばらく考えた後、思い出しました。

あ、「顔の無い村」の電話だ。

「顔の無い村」は、社会思想社のゲームブック「送り雛は瑠璃色の」に一緒に収録されていた作品。創土社から出ている「送り雛は瑠璃色の」には含まれないので注意。別巻として、今年春ごろ(?)出すようです(2008/11ごろの情報)なお、もともとは、どちらも、ゲームブック雑誌「ウォーロック」に掲載されていました(それぞれ加筆修正があるので、どれも同じものではないですが)

デリケートに好きして21st Ver

　ふと、なにげなく、Amazonのお勧め一覧を書籍(というか、コミック?)から、音楽に切り替えたら、古いCD(この時代だと、ちょーど、レコード→CD移行の時期)と復刻版/再編集版にまざって、こんなものが。
　もとの番組であるところの、「魔法の天使クリーミーマミ」の２５年(開始からなのか終了からなのか原作作成からなのかは不明)を記念して、セルフカバーCDで作成されたとか。なお、タイトルは、「デリケートに好きして(wqst century ver.)/大田貴子」なので、９割がた歌っている人(主人公の声も当てていた)の大田貴子さんのCDです。
# あのころは、新人でアイドル駆け出し兼声優で主人公・・・・とゆーパターンは多かったような。

　・・・いや、２５年を経てセルフカバーというのが、なかなか・・・・
# ゲストボーカルで水島 裕さんも引っ張り出されてます・・・

　なにはともあれ、元気でわらわらと活動しているというのは、良いことです。まる。