人生を豊かにするための暗号技術の話 - ネクストスケープ 2014/04/24...

株式会社ネクストスケープ　御中

パワーランチ：人生を豊かにするための暗号技術の話

2014.04.24

株式会社ネクストスケープ


コンピュータにおける暗号化とは

Last Updated: Sunday, April 9, 2023

___ _________ ___ 2www.nextscape.net

コンピュータにおける暗号化とは…

コンピュータが扱えるのは結局はビット列だけ。

　平文： 01001101 01110101 ( 平文は「ひらぶん」と読みます )に対して、ある暗号アルゴリズムを使って、　鍵： 11010100 11100011で暗号化すると、　暗号文： 11011100 11111101になる。同じ鍵で復号すると、平文に戻る、ということ。

よって、どんなにすぐれた暗号アルゴリズムであっても、総当り攻撃 ( ブルートフォース ) で全ての鍵を試すような攻撃は可能。むしろ、総当たり攻撃しか解析手法がない暗号アルゴリズムが一番優秀。

適当に決めた鍵で偶然復号できる可能性はゼロではないが、現実的には起こりえないので、実際に世の中で使われている。


共通鍵暗号方式



共通鍵暗号方式とは

鍵がひとつ。暗号化・復号いずれも同じ鍵を使う。

例： zip アーカイブ + 暗号化して、先方にメールで

zip ファイルとパスワードを送る


共通鍵暗号方式の例



共通鍵暗号方式の例：

DES ：鍵長 56bit 、ブロック長 64bit

3DES ：鍵長 168bit/112bit/56bit 、ブロック長 64bit

AES ：鍵長 192bit/168bit/112bit 、ブロック長 128bit


DES



DES ：鍵長 56bit 、ブロック長 64bit

1974 年、米 NIST （国立標準技術研究所）が暗号アルゴリズムを公募。 IBM の暗号が採用され、 1976 年に連邦規格として承認。

アルゴリズムは公開するが、鍵は秘密にすることでセキュリティを守るという考え方は非常に革新的であった。

それ以前は、アルゴリズムは国家機密だった。例えばエニグマ。第二次世界大戦でドイツが使用していた暗号機器で、連合国側が解読に成功したが、ドイツは終戦まで解読されていることを知らなかった ( 暗号アルゴリズムが適切かどうか判断できないとこうなる ) エニグマの写真

(Wikipedia より )


鍵長・ブロック長



鍵長 56bit の意味：

鍵は 56bit 固定。 ASCII 文字を 7bit とすると、最大 8 文字ということ。

ブロック長 64bit の意味：暗号化の対象とするデータ長は 64bit 固定。 128bit でも 72bit でも 56bit でもダメ。

→ では、長い文章の暗号化はどうするのか ?


暗号利用モード



暗号利用モード：ブロック長より長いデータを暗号化するための仕組み。

疑問：「 DES ブロック長 64bit で、データが 192bit なら、 64bit ごとに分割して、 3 回繰り返したらいいんでは ? 」

→ そうすると、入力と鍵が同じであれば、必ず同じ結果が得られてしまう。例： AAAA BBBB AAAA → XXXX YYYY XXXX

→ 暗号文の前半と後半が同じということは、平文の前半と後半も同じ、というヒントを与えてしまうのはまずいｓ。

なので、 1 ブロックを暗号化した結果を、次のブロックの入力の一部として利用する方法が考案された。それが暗号利用モード。 CBC ・ OFB ・ CFB とかいろいろあるが、 CBC を使っておけば OK ( 前述の分割して単純に暗号化するってのは ECB と呼ぶ。これは一番使ってはダメなモード ) 。


初期化ベクトル



初期化ベクトル ( 初期化ベクタ・ Initial Vector ・ IV ・ iv とも言う ) ：

暗号利用モードの最初のブロックに初期値として与えるもの。鍵ではない。秘密にしなくていいが、同じ暗号文を何度も送受信する場合は、繰り返し使うのはよろしくない。

相手に伝える方法は ?→ 暗号データの先頭にくっつけて送ってもいい (iv は誰でも読めてよい ) し、同じデータを二度と再送しないのであれば、あらかじめ iv=0x218b9a0e などと合意しておいてもいい。　　　　　　　　　　　　　　　↓こんなイメージ


パディング



「ブロック長より長いデータの場合はわかったけど、では短い場合は ? “a” の 1バイトを送りたいときはどうする ? 」

→ パディングすればよい。

A → A 07 07 07 07 07 07 07 A B → A B 06 06 06 06 06 06 A B C → A B C 06 06 06 06 06 A B C D → A B C D 04 04 04 04 A B C D E → A B C D E 03 03 03 A B C D E F → A B C D E F 02 02 A B C D E F G → A B C D E F G 01

などと、長さをブロック長に揃えてから暗号化する ( この例ではブロック長＝ 64bit) 。復号した後は、データの末尾を見ればパディング部分の長さがわかるので、その部分を削ればよい。


パディング



「 64bit ぴったりのときはパディングどうなるの ? 」→ 実装による。「 08 08 08 08 08 08 08 08 」をつけるものもあれば、何もつけないものもある。ここが異なると当然ながら復号できないので、あらかじめ合意しておく必要がある。

パディングにはいくつかやり方がある。 PKCS#7 を使っておけばいいのでは。・ PKCS#7 (PKCS#5) ≒ RFC2315 ・ ISO10126 ・ ANSI X.923 ・ゼロパディング


暗号化したいときは



「共通鍵暗号方式で暗号化する」となった場合、・暗号アルゴリズム・鍵長・初期化ベクトル (iv) ・鍵・暗号利用モード・パディング方式を決めること。


暗号化のサンプルソース



AesCryptoServiceProvider aes = new AesCryptoServiceProvider(); aes.BlockSize = 128; // ブロックサイズ (AES のブロックサイズは 128bit 固定なので 128) aes.KeySize = 128; // 鍵長。ここは 168 でも 192 でもよい。 aes.IV = Encoding.UTF8.GetBytes(@"!QAZ2WSX#EDC4RFV“); // IV // ↓ 鍵。 128bit を選んだので 128bit にする。 aes.Key = Encoding.UTF8.GetBytes(@“5TGB&YHN7UJM(IK<”); aes.Mode = CipherMode.CBC; // 暗号利用モードは CBC aes.Padding = PaddingMode.PKCS7; // パディングは PKCS#7 // 文字列をバイト型配列に変換 byte[] src = Encoding.Unicode.GetBytes(“ほげほげほげほげほげほげほげほげほげ” ); // 暗号化する using (ICryptoTransform encrypt = aes.CreateEncryptor()){ byte[] dest = encrypt.TransformFinalBlock(src, 0, src.Length); return Convert.ToBase64String(dest); // BASE64 化 }


余談： Base64 ・ Base62 ・ Base58



暗号化した文字列は、ほとんどの場合バイナリデータになる。URL 等のパラメータとして暗号データを渡す場合、 BASE64 を使うと「 + 」「 / 」「 = 」などの文字列ではまりがち。

例えば「 / 」は URL エンコードすると「 %2F 」だが、ブラウザ (ガラケー ?)によっては <a href=“foo?aaa%2F”> の % 自体を URL エンコードしてしまい、 %252F と送ってきたりする。また、「 + 」がスペースになったりする。

そういうときは、 BASE62 や BASE58 を使うと余計なところでハマらない。

BASE64 ： 0-9 、 a-z 、 A-Z 、 + 、 / の 64 文字と、パディングの =BASE62 ： 0-9 、 a-z 、 A-Z の 62 文字BASE58 ： BASE62 から、見た目が判別しづらい 0 ・ O ・ I ・ l を除外したもの。

BASE58 は flicker やビットコインで使われている。


DES の終焉



DES は鍵長 56bit 。ハードウェア・ネットワークの進化により、どんどん短い時間で解析可能になっている。

distributed.net という団体が、何度かクラックコンテストを開催しているが、 1999 年時点で 1日かからずに解読に成功している ( ただし専用ハード + 世界中の PC を使って ) 。 DES Challenge I 96日で解読 (1997 年 ) DES Challenge II-1 41日で解読 (1998 年 ) DES Challenge II-2 56時間で解読 (1998 年 ) DES Challenge III 22時間 15 分で解読 (1999 年 )


鍵長って大事



DES と RC5 という共通鍵暗号アルゴリズムの解読時間を比較してみる。

DES 40bit ：数秒～ 30秒で解読 (2001 年 CRYPTO2000 ランプセッション )DES 56bit ： 22時間 15 分で解読 (1999 年 )RC5 56bit ： 250日で解読 ( 鍵空間の 47% を解析したところで発見 )RC5 64bit ： 4 年間で解読 ( 鍵空間の 83% を解析したところで発見 )RC5 72bit ：開始から 11 年経過したが、 2014/2 時点で鍵空間の 3.1% しか解析できておらず、解読できていない

鍵長が増える → 鍵のパターン数が増える → 総当り攻撃で見つかりづらくなる、ということ。

「 128bit は 64bit の 2倍の鍵空間」ではない。2 の 64乗=18446744073709551616 倍の鍵空間を持つ。


3DES



3DES ：鍵長 168bit/112bit/56bit 、ブロック長 64bitDES3 ・ TripleDES と書くこともある。

「 DES 単体だと鍵長が短くのなら、 3 回 DES で暗号化すればいいんじゃない ? 」という投げやりな暗号方式。

3DES は、 DES で暗号化・復号・暗号化とする ( 暗号化を 3 回ではない ) 。「鍵長 168bit/112bit/56bit 」とはどういうことかというと… 1 回目の鍵： X 、 2 回目の鍵： X 、 3 回目の鍵： X → DES と同じ (56bit の強度 ) 1 回目の鍵： X 、 2 回目の鍵： Y 、 3 回目の鍵： X → 112bit の強度 1 回目の鍵： X 、 2 回目の鍵： Y 、 3 回目の鍵： Z → 168bit の強度

1 つの実装で 3DES にも DES にも対応できるようにしている。


公開鍵暗号方式とは



公開鍵暗号方式とは ?

共通鍵暗号方式は「鍵がひとつ。暗号化・復号いずれも同じ鍵を使う」であった。

「自分ひとりが使う」のであれば共通鍵暗号方式で問題ない例：他人に見られたくないファイルを暗号化してデスクトップにおいておく、など

しかし、他人とのやりとりを暗号化する場合、共通鍵暗号方式だと「どうやって鍵を相手に受け渡すか」が問題になる。

ネットワークは盗聴されているかもしれないので、ネットワークごしに鍵を渡すことはできない。電話は盗聴されているかもしれない。手紙は開封されるかもしれない。　→ 安全に受け渡す方法がない！ ( これを鍵配送問題といいます )


公開鍵暗号方式とは



そこで発明されたのが公開鍵暗号方式。

鍵が 2 つある。誰にでも公開してもよい公開鍵と、秘密にするべき秘密鍵。公開鍵で暗号化し、秘密鍵で復号することができる。

A さんに B さんからメッセージを送りたい場合：

1. A さんが公開鍵を世界中にばらまく2. A さんにメッセージを送りたい B さんは、 A さんの公開鍵で暗号化し、 A

さんに暗号文を送る。3. A さんは B さんから暗号文を受信し、 A さんの秘密鍵で復号する。

ここで「 A さん＝Webサーバ」「 B さん＝ブラウザ」とすると、 SSL/TLS となる。


RSA



そんな都合のよい鍵が世の中に存在するのか ?　→ 素数を使った RSA という暗号化方式が 1977 年に発見された。

素数の性質：・大きな素数を生成 (発見 ) するのは高速に行える。・大きな素数をかけあわせた数を素因数分解するのはとても時間がかかる。

この「非対称性」を使うことで「暗号化は簡単だけど、復号は難しい」を実現している。

例えば、 p=654673753499 (素数 ) q=242789071243 (素数 )のとき、 n=p*q は 158947632579190931529257 となる。ここまではコンピュータなら簡単に行える。しかし、 n (158947632579190931529257) を因数分解して p と q を取り出すことは難しい。これを利用して、 RSA においては「 n を公開鍵」「 p ・ q を秘密鍵」とすることで、公開鍵暗号方式の特性を満たしている。


RSA



> 「 n を公開鍵」「 p ・ q を秘密鍵」

上記はあくまでイメージであって、正確には下記。そんなに難しくはないし、 RSA のサンプルプログラムはたくさん見つかるので、ぐぐってみてください。--------素数 p, q を用意する。n = p * q とするp-1 と q-1 の最小公倍数 L を求める。e と (p-1)*(q-1) の最大公約数が 1 となるような e を求める。 → e は 3 とか 65537 がよく使われる。(e * d) % L = 1 となり、かつ 1<d<L を満たす d を求める。

公開鍵は e と n秘密鍵は d と n

暗号化：暗号文 = ( 平文 ^e) % n復号：　平文 = ( 暗号文 ^d) % n--------


余談：素因数分解と素数の生成



余談：

因数分解を行う場合、 2 で割れるか、 3 で割れるか、 5 で割れるか、 7 で割れるか…と順番に試していくのが最も簡単な方法だが、これだと時間がかかりすぎる ( 前ページの例だと n は 84bit なので、やろうと思えばできそうだが、実際に使われている RSA においては 1024bit や 2048bit の値を相手にしないといけない ) 。

数体ふるい法など、よりエレガントな方法はあるが、それでも時間がかかる。

一方、素数の生成 (発見 ) は、「ミラー - ラビン素数判定法」などの高速なアルゴリズムがある。ただし、あくまで「素数である可能性が極めて高い」という判定しかできない。(確定判定はできるが、時間がかかりすぎるので現実的ではない )


RSA ビット数



RSA のビット数 ( ここで言うビット数は、 n (=p*q) のビット数のことです )結論から言うと、 2048 ビットを使いましょう。

米 NIST (国立標準技術研究所 ) が政府標準の暗号を決定する際、「 RSA 1024 ビットは安全性が低いので使うな！でも 2010 年までは許す！」と宣言しました。これを受け、ベリサイン等の認証局も 2010～ 2012 年あたりで RSA 1024 ビットの受付を終了しています。なお、 RSA を発見した R さんと S さんと A さんが作った RSA セキュリティ社では、RSA 解読のコンテストをやってます。現在 RSA 768bit まで解読されています。

チャレンジ名ビット数終了時期

RSA-129 428bit 1994 年 4月 27日

RSA-140 466bit 1999 年 2月 2日

RSA-155 512bit 1999 年 8月 22日

RSA-160 ( ここまで桁数 ) 530bit 2003 年 4月 1日

RSA-576 ( ここからビット数 )

576bit 2003 年 12月 3日

RSA-640 640bit 2005 年 11月 2日

RSA-768 768bit 2009 年 12月 (Opteron2.2GHz 600個 ×3 年間に相当 )

RSA-1024 1024bit 未解読

RSA-2048 2048bit 未解読


RSA 512bit の小ネタ



●RSA 512bit の小ネタ：

2012 年に、 Google 採用チームからの「 Google で働きませんか ? 」というヘッドハンティングのメールを受信した数学者のザッカリー・ハリス氏。

このメールが本当に Google から届いたものか疑問に思った彼がメールをしらべているうちに、 DKIM (Domainkeys Identified Mail) を使った署名において使用されている Google の公開鍵が RSA 512 ビットであることとを発見。

Amazon EC2 にてインスタンスを数個立ち上げて解析プログラムを実行した結果、 72時間以内に鍵を発見し、 Google創業者のサーゲイ・ブリン氏から Google CEO であるラリー・ペイジ氏にあてたように見せかけたメールを送信した。返信はなかったが、 2日後に Google の鍵は 2048 ビットに変更されていた。

US-CERT がこの件を警告した結果、 Google 以外にも、 Microsoft ・ Y! ・Amazon ・ Apple ・ Twitter 等々で 1024bit 未満の不適切な鍵の使用が発覚。→ 「 RSA だから安全」ではない。適切な鍵長を使いましょう。


RSA のデータ長



RSA が扱えるデータ長：

RSA 1024bit のとき、扱えるデータは 1024bit あたりまで。RSA 2048bit のとき、扱えるデータは 2048bit あたりまで。

( 暗号化・復号においては n で割った余りが結果となるので、 n を超えることはありえない ) 。

長いデータを扱えないので、 DES などの共通鍵暗号方式と同様に、長すぎる場合の分割方法やパディング等が規格としてまとめられている (RSA_PKCS#1 v1.5 や、 RSA_OAEP 等 ) 。よって、実利用する場合は特に考えなくてよい。


RSA の欠点



RSA の欠点：

遅い！DES や AES 等の共通鍵暗号とくらべて 1000倍遅いと言われている。

よって、 SSL/TLS においては、共通鍵暗号方式と組み合わせて使われている。


RSA 以外の公開鍵暗号方式



●楕円曲線暗号 (ECC)y2 = x3 + ax + b といった楕円曲線において、掛け算的なことは簡単にできるが、割り算的なことは難しいという特性を用いたもの。サーバ・ブラウザ等の実装が進み、 2013 年あたりから ECC な SSL 証明書が発行されている。

ウリとしては、 ECC 256 ビットで、 RSA 3072ビット相当の強度を持ち、 RSA と比較して高速であること。鍵送信時のデータ量削減と、サーバ負荷軽減につながる。

ECC の欠点：certicom 社の特許料が不透明な感じ (?)MS の DRM では昔から使われている模様。

SSL における RSA4096/2048/1024 それぞれの処理速度 (X軸が新規 SSL のセッション割合、 Y軸が処理速度。傾きが大きいのがRSA4096 。小さいのが RSA1024)


RSA と公開鍵暗号方式



RSA は、秘密鍵で暗号化して公開鍵で復号できるが、逆に公開鍵で暗号化して秘密鍵で復号することもできる。

これは RSA がたまたまそういうつくりであるだけであり、公開鍵暗号方式全てにあてはまるものではない。


ストリーム暗号



ストリーム暗号：共通鍵暗号の一種。

ブロック暗号のように 64bit や 128bit などのブロック単位でデータを暗号化するのではなく、ビット単位またはバイト単位で暗号化できるもの。ブロック暗号より高速なのがウリ。

ストリーム暗号の例：・ RC4 ・ SEAL 等々

ブロック暗号で代用できるため、最近はストリーム暗号はあまり流行らないのかもしれない。


小ネタ： RC4 と ARC4



●小ネタ： RC4 と ARC4RSA 社が 1987 年に作ったストリーム暗号。仕組みは非公開であったが、あるメーリングリストに匿名でソースが投稿され、即ネットニュース等に転載され、世界中が知ることとなった。このソースは ” Alleged RC4” (RC4 だと言われている物 ) と呼ばれるようになり、” ARC4” “ARCFOUR” とも書かれる。 RSA 社は認めてはいないが、セキュリティ業界的には RC4 ＝ ARC4 ＝ ARCFOUR とみなされている。

無線 LAN関係の WEP ・ WPA や、 SSH ・ SSL/TLS 等で使われている。 WEP において RC4 の使い方の問題による脆弱性があり、なんとなくイメージが悪いような気がするが、 RC4 において致命的な問題があるわけではない。

ただ、致命的ではないが、そろそろまずいのではという話も出ており、 RC4 が生成する乱数に若干の偏りがある (2個目の数字がゼロになる確率が、他の数字より 2倍程度高い ) ため、 2^33～ 2^34 回程度観測を続けると HTTP cookie が盗聴できるレベルになるとのこと。

2013 年になって、 Microsoft が SSL/TLS で RC4 を無効化するようアドバイサリを出したり、日本政府推奨のリストから 128bit RC4 が外されたりしている。


ハッシュアルゴリズム



ハッシュアルゴリズム (ハッシュ関数 ) とは：

どんな長さのデータ、どんな内容のデータを与えても、決まった長さの値を返すもの。

同じ値を与えれば、必ず毎回同じ結果になる。

復号できないので暗号化ではない。鍵は存在しない。入力データのみで結果が決まる。

結果から、元の値を推測することはできない。

文字列ハッシュ値aa d404401c8c6495b206fc35c95e55a6d5

bb bfcc9da4f2e1d313c63cd0a4ee7604e9

cc 870c06c00566c4fb1861bb10f34d1904


MD5



ハッシュアルゴリズムの実例： MD5 (Message Digest Algorithm 5)

128bit の出力をするハッシュ関数。RSA の R さんが開発した。

例： Linux の md5sum コマンド % md5sum file.txt 30ad0c5b76090a9011e83a2b4482148a → file.txt の内容を入力値とし、ハッシュ値を出力 ( どんな長さのファイルを与えても、同じ長さになる )


SHA



ハッシュアルゴリズムの実例： SHA (Secure Hash Algorithm)

現時点では SHA-2 がよいと思われる。

SHA名称出力長備考SHA-0 160bit 使わないほうがよいSHA-1 160bit 使わないほうがよいSHA-2 (SHA-224) 224bit

SHA-2 (SHA-256) 256bit



SHA-3 (SHA3-224) 224bit

SHA-3 (SHA3-256) 256bit

SHA-3 (SHA3-384) 384bit

SHA-3 (SHA3-512) 512bit


強衝突耐性と弱衝突耐性



強衝突耐性：　　同じハッシュ値をもつ２つのデータの作りにくさ。

弱衝突耐性：　　あるハッシュ値を持つデータの作りにくさ。

例えば MD5 は、強衝突耐性は破られているが、弱衝突耐性は突破されていない。

強衝突耐性が破られているとは、同じハッシュ値が出力されるような 2 つのデータを簡単につくれるということ。ただ、現実的にはそれができたからといって大問題になるわけではない。

弱衝突耐性が破られたら、それは元データを変更しつつもハッシュ値を変えない、つまり改ざんが可能ということであり、全く使い物にならなくなる。


強衝突耐性と弱衝突耐性



MD5 の小ネタ：

オーストラリアにてオービスにてスピード違反として摘発されたドライバーが、写真データのハッシュとして MD5 を使用しているが、 MD5 は強衝突耐性が破られているためその写真は信用できないと裁判に訴えた結果、勝訴となり、違反取り消しとなった。

つまり「 MD5 には脆弱性があり、写真のナンバープレート部分を修正した上で、元の MD5 と同じ結果が得られるのだから、写真が改ざんされていない証拠にはならない」と主張して、認められたということ。しかし改ざんを行いつつもハッシュ値を変えない、とする場合は弱衝突耐性を突破する必要があるが、 MD5 では弱衝突耐性はまだ破られていないため、この主張はおかしい。

その後、警察 (?) が「 MD5 に加えて SHA-1 でもハッシュを取っているので証拠として有効である」と声明を出したらしい。

その後どうなったのか不明。


ハッシュの使いどころ



・改ざんの検出

・チェックサム

・パスワード保存パスワードを SHA-1 でハッシュ化した結果を DB に保存しておく。次回ログイン時は、入力されたパスワードを SHA-1 でハッシュ化し、 DB の値と一致すればログイン OK とする。

万が一 DB の内容が漏洩したとしても、ハッシュ化された値から元の値を求めることは困難なので、第三者がログインすることはできない。


レインボーテーブル



パスワード保存はハッシュ化しておけば安心、というわけではない。

例えば、適当な文字列とそれをハッシュした値のテーブルをあらかじめ作っておき、 DB に保存されているハッシュ値と照合するという手法がある。

しかし、文字列を 128bit 、ハッシュを 128bit として、 128bit 分のすべてのハッシュ値を計算しておくと、データ量が半端ない。9600000000000000000000000ペタバイトくらい必要。

文字列ハッシュ値aa d404401c8c6495b206fc35c95e55a6d5

bb bfcc9da4f2e1d313c63cd0a4ee7604e9

cc 870c06c00566c4fb1861bb10f34d1904

・・・・・・・


レインボーテーブル



そこでレインボーテーブル。「ハッシュ→平文」を変換を行う「還元関数」を用いる ( このとき、英数字のみなどと文字種を絞り込む ) 。赤枠部分だけ保存しておけばよい。

※上記画像は http://dev.classmethod.jp/security/rainbowtable/ より拝借。

http://md5decryption.com/ など、 Web 上で解読可能なサービスもある。

レインボーテーブルは MD5 に限らず、 SHA-1 ・ SHA-2 などにも適用可能。


salt (ソルト )



salt (ソルト ) = 「塩」。暗号化またはハッシュ化する際に、適当なデータを先頭や末尾にくっつけること。

例えば abc という脆弱なパスワードを使うと、レインボーテーブルや総当り攻撃を使って、ハッシュ値から元のパスワードが推測されやすい。

パスワード文字列ハッシュ値abc 900150983cd24fb0d6963f7d28e17f72

文字列ハッシュ値3N$.<_Q2abc 184d37f55640c50bae687a76abe0abea

例えば salt を “ 3N$.<_Q2” とし、パスワードの先頭にくっつけてからハッシュ値を計算する。 $ や < などの記号まで含めたレインボーテーブルは現実的には構築困難であるため、「パスワード自体の短さ」「文字種の少なさ」などの弱みを補うことができる。


salt (ソルト )



○salt には何を選べばよいか ?

・システム固有の文字列例 : NS37q2$+Z”x・システム固有の文字列 + user_id などの数字例 : NS37q2$+Z”x1234567・ランダム文字列

○salt はどこに保存すればよいか ?

・システム固有の文字列の場合 → DB でも設定ファイルでも・ランダム文字列の場合 → ハッシュ化したパスワードの先頭とか、 salt カラムを作ってそこに保存とか ※salt は秘匿する必要はない。


ストレッチング



ストレッチングとは

ハッシュ化する際に、 SHA-2 などのハッシュ関数を 1 回だけ使うのではなく、1000 回とか 1万回とか繰り返すこと。

総当り攻撃やレインボーテーブルとの照合する際に、ハッシュ関数を 1万回まわす必要が出てくるので、攻撃が難しくなる (時間がかかる ) 。

一方、パスワード設定やログイン時にハッシュ関数を 1万回まわしたとしても、1秒程度で処理が完了するため、サイト運営側としては「ログイン時に少し時間がかかる」程度の影響しかない。


SSL/TLS



SSL/TLS (画像は http://www.twsvc.com/about_ssl より拝借 )


SSL/TLS



サーバ証明書の例 (シマンテックのサイトより )

https なサイトにアクセスすると、自動的にサーバにある証明書を取得する。

これが公開鍵。

公開鍵で暗号化すると、サーバ側にしかない秘密鍵でしか復号できない。


SSL/TLS



SSL/TLS における共通鍵

共通鍵暗号方式は RC4 128bit 。


SSL/TLS



SSL/TLS における署名とは：

あるデータのハッシュ値を求め、公開鍵暗号方式の公開鍵・秘密鍵のペアのうち、秘密鍵で暗号化したもの。

公開鍵で復号することで、「秘密鍵を持っている人が署名した」ということを検証できる。

サーバ証明書の検証：「サーバから送られてきたサーバ証明書が正しいのか ? 」「第三者に通信が改ざんされているのではないか ? 」「別のサーバに転送されているのではないか ? 」という疑問を解決するためには・・・

サーバ証明書に含まれている署名を、ブラウザにあらかじめインストールされている「ルート証明書」で検証する。この検証が成功したら、ベリサイン等の認証局で発行したものである、との確信が得られる。


暗号技術まとめ



共通鍵暗号方式　ブロック暗号 : AES ・ DES ・ 3DES 等　ストリーム暗号： RC4 ・ SEAL公開鍵暗号方式　 RSA　 ECC ElGamal 等ハッシュアルゴリズム　 MD4 MD5　 SHA-1　 SHA-2署名 RSA DSA (ElGamal署名を改良したもの )プロトコル SSL/TLS SSH


おしまい



人生を豊かにするための暗号技術の話 - ネクストスケープ 2014/04/24...

Technology