オープンソース化による安全性について

ユーザー様から「アタッシェケース」をオープンソース化するにあたっては「安全なの？」という懸念も少なからず、 いただきました。

「絶対安全」というのはありませんが、作者としては、むしろ以下のいくつかの理由により、オープン化した方が、 安全と考えています。

そもそも暗号化アルゴリズムがオープン

そもそも、アタッシェケースで使っている暗号アルゴリズムである AES ( Rijndael ) の仕様はオープンになっており、 全世界で広く使われています。

暗号アルゴリズムとは、ようするにデータを「秘密鍵」によって「暗号化する手順」を示したものでしかありません。 ですので、秘密鍵の管理が万全で、その手順を正しく使っているのなら暗号化は安全と言えます。

ここで言うなら、あくまで暗号化される際の「キー（パスワード）」の扱いが重要になるといえます。 パスワードさえ、あなたの手元にあれば、安全は保たれていることになります。

当然、将来的に、他の暗号アルゴリズムにあったような、脆弱性が発見されることがあるかもしれません。 どのようなパスワードを設定しても、脆弱性を突き、 かつ膨大な計算が行えるマシンを使って逆計算を行うような手法を用いれば、 元に戻せてしまうようなセキュリティーホールの発見があった場合です。

ただ、それでも全世界に公開されていることで、すぐに情報開示が行われ、 早急な対応が可能になるという利点もあります。

より透明性が高まる

みなさんの目にソースがさらされることになるため、暗号化アルゴリズム以外の箇所にある潜在的な脆弱性や、 ＰＣ全体の動作に影響を及ぼすようなメモリリークなどが発見され、その修正が行われる可能性が高まります。

すでにいくつかのメモリーリークなどが発見され、バージョンアップの度に改良・修正が行われています。

バックドアを仕掛けられていないかという懸念

オープンソースになることで、バックドアや悪意あるスクリプトが仕掛けられていないか？ という懸念から解放されます。

オープンソース化した現在でも、アタッシェケースの配布には、僕の手元にあるPCでビルドし、 インストーラーに仕上げて公開・配布しています。

もちろん僕は、使っていただくユーザーさんのことを念頭において開発していますので、 誓ってウイルスやバックドアを仕掛けたり、 意図的な不具合を入れたりすることなどはしていません（もちろんそんなことをしたら犯罪なのですが）。

とはいえ――　それさえもちょっと信用できない・・・と思われる方がいらっしゃるのもたしかです。 特に重要な機密情報を扱う政府機関、または大手の企業、 あるいはシステムに組み込みたいと思っている開発会社さんなどです。

その場合は、オープンソースですので、究極は自分の手元にソースをダウンロードしてきて、 そういった悪意ある箇所がないか確認した上で、自身の手でビルドすることが可能です。 開発環境さえあれば、そのまま同じものがつくられるはずです。

まとめ

というわけで、「アタッシェケース」はオープンソース化することで、安全性が低くなるよりも、 むしろ、透明性が増し、安全性が高まる方向に進むと考えています。

暗号アルゴリズムについて

『アタッシェケース』では、暗号化アルゴリズムとして AES ( Rjindael ) を使用しています。

Rijndaelとは、ベルギーの数学者 Joan Daemen 氏と Vincent Rijmen 氏によって開発された 新しい暗号アルゴリズムで、2000年10月にアメリカ政府標準技術局（NIST）によって、 次世代の暗号化標準 AES（Advanced Encryption Standard）として選定されたものです。 一般公募として行われ、その他の暗号アルゴリズム最終候補（ファイナリスト）としては、 Twofish, RC6, MARS, Serpent があります。

それまでは、IBM が開発した DES と呼ばれる暗号アルゴリズムが広く使われていましたが、 コンピュータの著しい性能向上や、アルゴリズムの解析が進むことにより、 強度が心許ないものになってしまいました。新たな暗号アルゴリズムを採用する必要が出てきたのです。 そこへ現れたのが、AES（Rijndael）です。

「Rijndael」の特徴としては、鍵とブロックの長さをそれぞれ 128, 192, 256 ビットの中から指定できるようになっており、さらに拡張することも可能です。 AESではブロック長に限って128ビットの固定と規定されています。

また、その他ファイナリストの暗号化アルゴリズムにあるような、 暗号化中のビット変換をFeistel構造（ファイステルネットワーク）という一般的なアルゴリズムで行うのではなく、 SPN 構造といった３つの異なる独自変換を行うことで、強力な暗号化を実現しています。

AES は、仕様が公開されていることが原則です。そのため、誰でもが無料で利用でき、 自由にソースへ組み込むことができるのはもちろんですが、世界の研究者たちが常に検証を行っていますので、 暗号強度については折り紙付きです（たとえ破られたとしてもすぐに情報が得られます）。

また、AES はさまざまなプラットフォーム上で動くことも前提となっていますので、 処理速度も高く、優れたアルゴリズムとなっています。

2000年に正式採用されてから20年余り、アメリカでは DES から AES への乗り換えがだいぶ進んでいると聞きます。 また、日本でもソフトウェアなどへの組み込みが増えてきて、実績も証明されつつあるようです。

AES（Rijndael）についての情報については、以下のサイトで入手することができます。

Advanced Encryption Standard (AES) - NIST（英文）
https://www.nist.gov/publications/advanced-encryption-standard-aes

BrianGladman/aes: AES code - GitHub（英文）
https://github.com/BrianGladman/aes

また、その他、様々なプラットフォーム上で動くソースコードは以下に掲載されていますので、 興味のある方は利用されてみてはいかがでしょうか。

AES implementations - Wikipedia（英文）
https://en.wikipedia.org/wiki/AES_implementations

また、こんなインターネット、ブロードバンドのご時世ですが、 個人でも暗号化アルゴリズム（またそれを含むソフトウェア）を海外へ輸出すると、 国際条約に違反する恐れがあります。

以前に比べ、だいぶ規制は緩和されたとはいえ、アメリカなどが認定するテロ支援国家への軍事目的等の輸出は、 今でも法的に罰せられる可能性があります。たぶん明らかな意志で自ら行った場合のみでしょうけども、 念のためご注意を・・・。

ちなみにテロ支援国家とは2021年現在、

イラン、シリア、キューバ、北朝鮮の4カ国です。

暗号化モード

アタッシェケースは、古くは（ver.1.**）まで、 「ECB（electronic codebook：電子符号表）モード」と呼ばれる方式で暗号化していました。 単純にブロックごとに暗号化して、そのまま暗号化ファイルに書き込む方法です。 図に表すと、以下のような感じになります。

同じファイル、同じパスワードであれば、まったく同じ中身の暗号化ファイルが生成されます。 なのでこの方式では、その暗号化の特徴からブロック単位での解読がしやすくなってしまいます。

ただ、多少なりとも「検証のしやすさ」という弱点があることは否めません。 そこで、『アタッシェケース ver.2』から、「CBC（cipher block chaining：暗号ブロック連鎖）モード」 と呼ばれる方式で暗号化することにしました。簡単な図式にすると以下の通り。

上図を見れば明らかですが、まず最初に「初期化ベクトル（Initialization Vector）」と呼ばれる、 乱数によるブロックデータを生成します。

これをデータブロックと排他的論理和（XOR）をとってから、暗号化ファイルへ書き込んでいます。

つまり最初の乱数データを元に、データを連鎖的にからめ、巻き上げていくように、 暗号化データを生成していきます。この結果、最初に乱数値が与えられることで、 同じファイル、同じパスワードで暗号化しても、毎回同じ中身になることはありません。 これにより、暗号化特徴からの「検証のしやすさ」の弱点をなくすことができます。

では、最初に乱数を与えて、どうして元に戻す（復号する）ことができるのでしょうか？ 　それは以下の図の通りです。

最初に与える乱数によるブロックデータも、ファイルに書き込まれているので、 元に戻すことができるのです。

では、ファイルにその乱数によるブロックデータが書き込まれてあっても、 解析の糸口にされたりしないのでしょうか？

それはできません。暗号化されたブロックデータをまず解析して復号化しない限り、 たとえ乱数データが見えていても解析の何の役に立たないからです。 乱数データが元となって、このチェインを解きほぐし、解析の端緒にすることはできません。

RFC2898によるキー派生

アタッシェケースのVer.3以降から、 RFC2898 に基づいたキー派生により、データのパスワードキーと、初期化ベクトル（IV）を導出する仕様に変更しました。

たとえば16文字までパスワード文字列を指定できるのに、「a」と一文字だけにしてしまうと、 15文字は空いてしまうということになります。

そこで、入力されたパスワードからランダムな文字列を生成して、 きちんと16バイト埋めた状態で暗号化した方がより安全であるというわけです。

具体的には、 「PKCS #5: Password-Based Cryptography Specification Version 2.0（パスワードベースの暗号化仕様）」 に基づき、 ソルト（まさにお塩）となる乱数を混ぜ込んでパスワードベースのキー派生を1,000回繰り返した後の、 派生キー、 初期化ベクトルを順々に出力し、それぞれを暗号化の際のキー、初期化ベクトルに使用しています。

とはいえ、この対策を講じても、パスワードの総当たり攻撃（ブルートフォースアタック）に、 無力なことには変わり有りません。パスワード文字列は、できるかぎり長い文字列を推奨します。

SHA-1からSHA-256へ

「SHA」とは、Secure Hash Algorithm の略で、 メッセージダイジェストアルゴリズム（Message Digest Algorithm) の一つです。 大きなサイズのデータを、固定長の小さなサイズのデータ列に縮約（要約）するためのアルゴリズムです。

同じデータであれば、必ず同じ縮約されたデータになるので、そのファイルの正当性をチェックしたり、 パスワードをそのまま保存するのではなく、そのメッセージダイジェストを保存して比較したりするなどして、 セキュリティーを強化する目的で使用されます。

ファイルを少しでも編集すると（たとえ1バイト変更するだけでも）、 まったくちがうメッセージダイジェストが出力されます。たとえて言うなら、 そのファイルの「指紋」のようなもので、固有の値が生成されます。

もちろん、どのような大きなファイル（データ）であっても、小さいデータに縮約されるので、 異なるデータでも同じ結果になることは完全には否定できませんが、その可能性はきわめて低いため、 実用上問題ないとされています。

アタッシェケースでは、パスワードファイルにのみ、 SHA-1ハッシュが使われてきました。ただ、最近になってSHA-1の脆弱性が指摘されています。 脆弱性の内容から、「影響は軽微である」とする意見や、アタッシェケースでの使い方からすれば問題ないとも言えますが、 最近では、より安全性の高い、SHA-256や、SHA-3などへの移行が進んでいます。 そこで、アタッシェケースでも、パスワードファイルで使うハッシュに、SHA-256を採用することにしました。

よって、過去にパスワードファイルで暗号化したファイルは、ver.3から復号できなくなっています。 過去のものは、古いバージョンで一度復号されてから、再度ver.3以降で暗号化してください。

圧縮アルゴリズムについて

圧縮処理については、 zlib ライブラリ を組み込んで使っています。 .NET Framework 4.5 にある、 「 DeflateStream」を使って圧縮されているので、内部的に zlib が選択されるようです。

zlib とは、 zip や gzip に使われている圧縮アルゴリズムをライブラリ化したもので、 フリーとして公開されているものです。圧縮率が高く（lzhよりも高いと言われていますがデータの中身に依存します）、 処理も高速です。何よりもアーカイバDLLを必要とせずに、圧縮機能を独自に用意できるメリットが大きいです。

ちなみに、グラフィックデータフォーマット「PNG」でも zlib 圧縮が使われているようです。