Web、サーバ、ソフトウェア、バグ・脆弱性 などの情報を何人かで集まって書いていく IT/Web情報系ブログ

2ch APIキーの今よりはましな難読化方法【Jane Style】

投稿日:   投稿者:xx2zz

2ch.net専用ブラウザのAPIの運用が始まって間もなく、APIの使用許諾元である株式会社ジェーンの提供する2ch.net専用ブラウザ『Jane Style』からAPIの仕様や秘密鍵が漏れてしまった模様。

最初に公開されたバージョンでは鍵が実行ファイルに生の文字列として埋め込まれていたようでテキストエディタで開いただけで丸見えだったとか。(ソースは2ch)

さらに、割られた鍵をユーザが入力することを前提にした既存ブラウザ用のプロキシなんかが開発されたり、開発者の技術力が低いだの言われたり、散々な状態になっていますね。

一度、バージョンアップで鍵を暗号化(というか難読化)して解析を困難にしたようですが、
開発者の奮戦虚しく、結局そのバージョンも公開後約2時間で秘密鍵が割られてしまっています。

スポンサーリンク

ではどうすればよいのか?

そのバージョンでは、暗号化(というか難読化というかXOR)した鍵は使用する直前に復号化したりといろいろ工夫しているようですが、そんな小細工をせずとも、HMACなら秘密鍵を不可逆(厳密には元の鍵を割り出すのは非常に困難)な状態でプログラム中に埋め込めるはずです。

HMACの計算方法をよく見れば、その方法に気付くはず。

ipad = the byte 0x36 repeated B times
opad = the byte 0x5C repeated B times.

To compute HMAC over the data `text’ we perform

H(K XOR opad, H(K XOR ipad, text))

(RFC 2104 2. Definition of HMAC より引用)

秘密鍵を不可逆な状態で埋め込む方法

RFC 2104 4. Implementation Note

HMAC is defined in such a way that the underlying hash function H can
be used with no modification to its code. In particular, it uses the
function H with the pre-defined initial value IV (a fixed value
specified by each iterative hash function to initialize its
compression function). However, if desired, a performance
improvement can be achieved at the cost of (possibly) modifying the
code of H to support variable IVs.

The idea is that the intermediate results of the compression function
on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed
only once at the time of generation of the key K, or before its first
use. These intermediate results are stored and then used to
initialize the IV of H each time that a message needs to be
authenticated. This method saves, for each authenticated message,
the application of the compression function of H on two B-byte blocks
(i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be
significant when authenticating short streams of data. We stress
that the stored intermediate values need to be treated and protected
the same as secret keys.

Choosing to implement HMAC in the above way is a decision of the
local implementation and has no effect on inter-operability.

Proof-of-Concept

では、本当に元の秘密鍵を持たずに、正しいMAC値を計算できるのかどうか、試しにCで書いてみました。

元のHMACの秘密鍵は「VtzWNOHhwgMhJdWnAx4ngyBOkEuEnM」です。
(『Jane Style』と同様に半角英数ランダム30文字で作成)
当然、上のコード中にはこの文字列は含まれていませんし、処理の途中で現われることもありません。

ちゃんと、この秘密鍵を使って普通に計算した場合と同じMAC値が出力できています。

実際に使う場合はさすがにこれではシンプルすぎるので、全体的にダミーの計算や値なんかを混ぜてより複雑にしたほうがよいでしょう。

しかし結局これでもIVを抜かれたら同じこと。
それが30文字の半角英数の文字列(元の秘密鍵)か謎の値かの違いだけです。
それでも、いままでのように明らかに秘密鍵と分かる文字列が2chのスレに貼られることはないですし、現状のAPIキーを入力させる方式のプロキシなんかは改修が必要になるのである程度の時間稼ぎとある程度の開発者の名誉挽回にはなるんじゃないでしょうか。
プログラムの改修は既存のHMACライブラリをそのまま使っている場合それが使えなくなるので結構面倒でしょうしね。

というわけで、じぇーんの人はこれ使うといいですよ。

- 提案 , , , ,

Message

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連記事

関連記事はありませんでした