暗号化通信 並びに swf の暗号化についての調査を少しずつ開始。

暗号化通信

いくら暗号化通信を行おうとも swf 自体を解析されてしまえば意味が無い、といった認識がありました。ざっと調査した結果 その認識は変わらず。とはいえ暗号化しないと、誰でも簡単に不正なリクエストを行うことが可能となってしまうため、重要なデータを扱う swf では暗号化は必須となります。

swf は Google App Engine 上で動作させることを予定しており、AS3 ←→ Python 双方向に暗号化通信を可能にすることを第一の目標とします。

暗号化の方法を調べてみると、共通鍵暗号方式と公開鍵暗号方式、そして両者を組み合わせたハイブリッド暗号方式等が見つかります。以下はハイブリッド暗号方式に関しての参考 URL です。

　http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1065429575
　http://itpro.nikkeibp.co.jp/article/COLUMN/20060620/241303/

共通鍵暗号化通信、公開鍵暗号化通信それぞれサンプルを制作した後、ハイブリッド暗号方式に挑戦してみようと思います。ハイブリッド式にするのは、上記 URL 内にあるような両者の利点をとるため、というのではなく、スクリプト難読化のため(不正なリクエストを送り難くするため)の対処といえます。

AS3, python 共に暗号化に関する情報は検索すると結構見つかります。MD5, RSA あたりがキーワードになるでしょうか。

Adobe のサイトでも少々解説がありました。

　より安全なSWF Webアプリケーションの作成
　http://www.adobe.com/jp/devnet/flashplayer/articles/secure_swf_apps_12.html

ただし、上記 URL の以下の文章は誤りではないでしょうか。

非対称暗号化方式を使用する場合は、SWFファイル内に公開鍵を格納しても、
脅威にさらされることはありません。

第三者がSWFファイルを逆コンパイルして鍵を盗んだとしても問題はありません。
攻撃者が不正な暗号化済みデータをサーバに送りつける可能性もありますが、
サーバ側で、暗号化が行われているかどうかにかかわらずデータの検証を行うよう対策を施していれば、
問題はありません。

サーバ側でデータの検証を行えばよい、とありますが、データを作る側のロジックは swf 内に存在するため、ロジックが解析されてしまえば不正なデータは作れてしまうような気がします。

swf 暗号化

まず、どれくらいの精度で解析可能なんだろうかと、世にある swf の解析ソフトを試用してみました。
swf バイナリ解析を勉強していた時、相当これはややこしいな、と感じていたため、解析ソフトも大した解析はできないのではないか？などと思っていましたが、いやはや実際に試用してみてびっくり。クラスパッケージ構造そのまま、ソースファイルの内容ほぼそのままに解析されました。あまりのそのままさに、ブーッと吹いてしまいました。暗号化通信対処を行なっても、その処理箇所がどうなっているのか知識のある人ならばすぐに見ることができてしまいます。

これは手詰まりか、と思いましたが、次に「swf 難読化ソフト」の試用を行って見ました。ソフト名は secureSWF です。試用してみた結果、解析ソフトで解析したとしてもソースファイルの内容は何が書かれているのか分からないような難読化が行われました。ディレクトリ構造やらクラス名やら何から何まで解析結果はめちゃめちゃな状態になり、これを解読するのは無理と言ってもいいような状況ではないでしょうか。

ただし、secureSWF によってクラス名等変更されているのが原因かどうか、外部 swf を読み込む箇所で動作が停止してしまう現象が発生しました。secureSWF の Identifiers Renaming タブに、クラス名や変数名等 rename 設定を任意に行うことができるような箇所があるので、その設定によってこの問題は解決するかもしれません。

secureSWF のデモダウンロードページを見てみると、FDT Plugin バージョンというものも用意されている模様。これはなんとか上記問題を解決し、導入を検討してみたいところです。

まとめ

暗号化通信並びに swf 暗号化、双方が問題なく可能になれば、サーバと swf とのデータのやりとりを行う処理にて、最低限の対策はとった と言うことができそうです。

[ FLASH ] [ tips ] [ update ] 投稿者 siratama : 2011年10月31日 16:23