追記(02.06.2018) : URLが間違えていたので直しました. 追加資料としている以上, 締切後の変更はアウトだと思うので誤字等はそのままにしてあります.
追記(14.06.2018) : 問1~3までを公開しました.
セキュリティキャンプTLSゼミの応募課題(の問3)です.
1と2はそのうち..
"基本/応用からそれぞれ1つずつ"と問題に書いてあるので複数書くのはNGかな〜と思い申し込み時は指示通りにしましたが, 他のトピックについても調べてまとめてみました. (全部記入していても大丈夫だったと思う)
いわゆる追加資料です.
最後2週間は入試の願書書いたりその他関連書類書いたりしていたので進捗がかなり滞ってました.
* キャンプの課題申し込み締切が過ぎたら公開します
* 実は来週編入試験
--------------------------------------------
[問1]
TLS 1.3とTLS 1.2以前の間にはいくつか共通点があります. 例えば通信の最初にClient Helloを送信することであったり,master secretを使って暗号化鍵を生成したりといった要素についてです. しかし, 逆に言えばTLS 1.3はそれ以前に比べて非常に多くの変更点・改善点が存在しています. 例えば今までよりも早い段階で暗号化が始まったり, 利用可能な暗号化スイートの種類がかなり絞られたりといった点が挙げられます. そこで, TLS 1.3とそれ以前について調べ, TLS 1.3で変更された点の中でもあなたの気になったものについて, どれだけ長くてもよいので, 詳しく解説してみてください.
--------------------------------------------
暗号スイート : SSL/TLSは暗号通信の枠組みを提供するものなので, 使用する暗号技術は自由に取り替えることができる.
ただし, クライアントとサーバ間では同じ技術を使用する必要がある.
そこでSSL/TLSではオススメの技術セットが提供されており, これを暗号スイートと呼ぶ.
https://www.watchguard.co.jp/security-news/ietf-formally-approved-tls-1-3.html
・TLS1.2以前用の暗号スイートは1.3からは使えないし、TLS1.3用に新設された暗号スイートは1.2以前では使えない
互換のためにはClientHelloのCipherSuiteフィールドにTLS1.2以前用と1.3用の両方の暗号スイートを書き並べる必要がある
・ハンドシェイクの省略による0-RTTの削減
・0-RTT(ゼロラウンドトリップタイム再開)
0-RTTとは、クライアントが暗号化されたアプリケーションデータとセッション再ネゴシエーションメッセージを一緒に送信できるようにすることで、接続の再開を高速化する新しいネゴシエーションモードである。
これまでのTSLネゴシエーションモードとは異なり、暗号化されたデータの送信前にクライアントとサーバが全てのハンドシェイクを完了する必要がない。
・全ての静的なRSAおよびDiffie-Hellman暗号スイートの削除
TLS1.3ではPerfect Forward Secrecyを提供する暗号スイートだけが許可される。
PFSがないと、RSAの秘密鍵やそのほかの事前共有鍵をサーバーから不正取得した攻撃者がそのサーバーとの間で送信される全てのSSL/TLSトラフィックを解読できてしまう。
PFSがあればセッションごとに新しい一意の鍵が使用されるため1つのセッションが攻撃されてもほかの全てのセッションに影響することはない。
・危殆化した暗号の廃止
“危殆化した暗号”とはForward Secrecy でないCipherSuite(RSAのみを用いたもの)や, 認証つき暗号でないCipher Suite
RSA_Diffie-Hellman暗号スイートは削除された.
Forward Secrecy
サーバーの秘密鍵が暴露された場合でも, 過去に暗号化によって通信されたデータの安全性を守ろうとする考え方.
実用されているのはDHE, ECDHEである.
この方式では, データの暗号化の際に, サーバーの 秘密鍵/公開鍵 を利用するのではなく, サーバーとクライアントそれぞれに秘密鍵を持たせるようにしている.
第三者がこの方式で暗号化されたデータを復号するには2つの秘密鍵を入手しなければならないため, 片方の鍵が流出してもデータの安全性は守られる.
さらにDHE, ECDHEでは秘密鍵は固定ではなく随時変更されるため, 事実上, 第三者による解読は不可能であるとされている.
暗号化だけでは通信相手の特定ができずMan in the Middle攻撃が可能になってしまうので, SSLでは証明書と組み合わせて使用する.
https://rms-digicert.ne.jp/howto/basis/forwardsecrecy.html
・通信はServerHello以降で全て暗号化される
・鍵導出関数が再構築された
・ハンドシェイクステートマシーンは一貫性とChangeCipherSpecのような余分なメッセージを取り除くための再構築を行なった
・楕円曲線やed25519やed448のような新しい署名アルゴリズムを基本仕様とした
・TLS1.2でのNegotiation Mechanismが廃止された.
・PSKに基づく以前の暗号スイートと同様に, サーバーサイドの状態にかかわらずセッションの再開は新しいPSK交換によって置き換えられた.
TLS draft https://tools.ietf.org/html/draft-ietf-tls-tls13-26#page-15 より
-参考文献-
TLS1.2とTLS1.3の違いは何？
- https://www.wolfssl.jp/wolfblog/2017/06/16/tls1-2-tls1-3/
暗号技術入門 第3版
solfSSL - TLS1.3 beta
https://www.wolfssl.jp/wolfsite/product-wolfssl-tls13/
--------------------------------------------
[問2]
問1で触れたとおり, TLS 1.3ではTLS 1.2以前と比較したときに非常に多くの変更点・改善点が存在します. この背景の一つに, TLS 1.2までのSSL/TLSに対していくつもの脆弱性が指摘されてきた歴史があります. そこで, 今までSSL/TLSに対して提案されてきた脆弱性を調べ, その中から気になったものを1つ, ないしいくつかピックアップし, 原理を詳しく解説してみてください.
--------------------------------------------
SSL3.0徹底解剖
http://moro-archive.hatenablog.com/entry/2014/11/04/042754
・Padding Oracle攻撃
パディングを使った攻撃
https://qiita.com/n-i-e/items/838df87a977fb213bedb
・BEAST攻撃
暗号化された通信からCookieを解読することに成功
・Lucky Thirteen攻撃
・POODLE攻撃
TLS1.0/1.1においても同様に発見されたため非推奨である.
https://www.openssl.org/~bodo/ssl-poodle.pdf
・ROBOT攻撃
RSAのパディングに対する脆弱性
Bleichenbacherが帰ってきた.
**CBC
後述するPOODLE, BEAST, LUCKY THIRTEEN攻撃が可能になっている原因(?)
ブロック暗号における処理方式の1つ.
暗号化したいデータを固定長のブロックに分割し, 最後のブロックが固定長に満たない場合にはパディングを足して長さを揃える. このパディングがこれらの攻撃の鍵となる.
-暗号化
平文ブロックP_iを暗号化する前に, 暗号文ブロックC_{i-1}とXORをとる.
P_1に対しては初期ベクトルIVとXORをとる.
-復号
暗号文ブロックC_iに復号処理を施し, C_{i-1}とXORをとるとP_iが得られる.
複合後C_1に対しては初期ベクトルIVとXOR.
*Padding Oracle攻撃
2002年に発表された. (https://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf)
仕様化されているCBCでは, パディングに使う文字列はパディングの長さと同じものをセットするようになっている.
パディング長が1であれば1, 2であれば22, …
この仕様ではパディングが改ざんされたかどうかをチェックする仕組みは実装されていない.
-攻撃方法
解読したい対象ブロックCに攻撃用ブロックyを連結した y || C をCBCに対して送信する.
yの末尾1byteを y = y XOR 1 としておくと, 復号後の対象ブロックCとyが同じ値だった場合,
y XOR 復号後C で得られる p の末尾が1になる.
CBCはこの値が元から1なのか, 改ざんされた結果1になったのかをチェックできないため, 正常なパディングであると判断してしまう. 対象ブロックCの1つ前のブロックとXORをとると目的の値が得られる.
SSLで利用されるCBCにはメッセージ改ざんをチェックするハッシュ値が付与されているため, 攻撃ブロックの影響がパディング以外の部分に及ぶと別のエラーが起きる. また, この攻撃を行うためには通信パケットを全て傍受する必要があるなどハードルが高いため当時はあまり問題視されなかった.
*BEAST攻撃
SSL3.0で暗号化された通信からCookieの値を解読することに成功した攻撃.
Paddling Oracleと異なり, レスポンスを元に解読するのではなく暗号化ブロックを比較して平文を得ようとする攻撃である.
暗号文を比較し, 一致する暗号文が得られるまで攻撃を繰り返すことで解読する.
Cookieが持っているセッションIDが盗聴され, アカウントの乗っ取りに発展することがある.
本来のCBC暗号モードでは, 同じ暗号文にならないように初期ベクトルIVを使っているが, SSL3.0やTLS1.0の仕様に欠陥があり, 前回の通信の最後の暗号ブロックを次回の初期ベクトルとして再利用する仕組みになっている. (Nonceではない? IVの再利用はAES-GCMの欠陥でもある)
つまり. 通信を傍受できれば次に利用される初期ベクトルがわかる.
攻撃ブロックにIVをXORしておくと, 1ブロック目のXORを無かったものにできるので暗号化アルゴリズムだけを攻撃の対象にできる.
*LUCKY THIRTEEN攻撃
Padding Oracle攻撃に成功している.
**TLSパケット
TLSのパケットは
ヘッダ || 平文 || HASH(平文) || パディング
で, 平文 || HASH(平文) || パディング を暗号化する
**TLSパディング
パディング長がnの時, (n-1)をn個埋める.
例えばパディング長が2であれば 0x01 0x01 を埋める.
**TLSMAC
TLSでよく使われていたHMAC-SHA1では20bytesのMACを生成する.
HMAC-SHA1はデータ長によってハッシュ処理の回数が異なる.
55bytes以下であれば4回, 56bytes以上は5回になる.
攻撃者が暗号ブロックCを復号したい場合,
ヘッダ || ブロック1 || ブロック2 || 調整用ブロック || 対象ブロックC
のパケットを復号者に送りつける.
復号者は対象ブロックCを
復号アルゴリズム適用後の対象ブロック XOR 調整用ブロック
で得る.
このブロックは下記のどれかに分類される.
1 パディングエラー
2 0x00で終わる(1byteパディング)
3 0x01 0x01 で終わる(2bytesパディング)
4 その他
3の場合, 復号後Cの末尾2bytesは
調整用ブロック末尾2bytes XOR 0x01 0x01
で得られる.
1/2**16 の確率でこのケースが得られ, エラーが返ってきたタイミングによってちゃんと得られているかどうかを判断する.
一種のタイミング攻撃である.
最初の2bytesを得る事ができれば, 残りは1/2**8 の確率で当てる事ができる.
**LUCKY THIRTEENタイミング攻撃
上記の復号パターンを考えると, 3のときだけバイト数が少なくなりハッシュ処理の回数が減るので
このケースが得られた場合は処理にかかる時間が他と異なる.
Lucky Thirteen の攻撃手法
http://dec9ue.hatenablog.com/entry/2013/03/24/134055
*POODLE攻撃
SSL3.0の仕様では, パディング長がブロック長の範囲ないかというチェックのみを行い, 残りのパディングの部分にどんな値が入っているかは確認しない.
そのため, 末尾の値が正しくなっていれば正当なパディングがセットされていると判断してしまう.
POODLEはこれを利用している.
*ROBOT攻撃
Return Of Bleichenbacher’s Oracle Threat を略してROBOT攻撃.
20年前に発見されたRSAに対するBleichenbacher攻撃が今でも可能であることがわかった.
鍵交換時の処理の不具合(PKCS #1 v1.5 padding)により, 適応型選択暗号文攻撃に対して脆弱になっているTLSサーバーが攻略される.
TLSサーバーの秘密鍵でRSAの復号化と署名が行えるという脆弱性である.
RSAの鍵交換だけを利用しているホスト(サーバー)は割と危険.
攻撃者はトラフィックを記録して復号するかもしれない.
ForwardSecrecyを利用しているホストに関しては, RSAのこの脆弱性に対するリスクは攻撃者がどれくらい高速に処理ができるかに依る. おそらく中間者攻撃も可能であるが何度が高いので多分実行されない.
ROBOT攻撃が成功すると, 第三者がROBOT攻撃に対して脆弱なTLSサーバーの通信記録を入手した場合, この通信記録を解読して通信の内容を把握することを可能にする.
鍵交換フェーズを含む全体の通信記録が残っており, その交換フェーズが脆弱である場合, 交換される鍵を復元することも可能になる. 純粋に暗号化されたデータだけであれば解読は困難になる.
交換される鍵を復元できれば, 暗号アルゴリズム, 鍵, 暗号データが揃うので暗号データの解読は容易になる.
The ROBOT Attack
https://eprint.iacr.org/2017/1189.pdf
PKCS #1 v1.5
http://inaz2.hatenablog.com/entry/2016/01/26/222303
http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf
暗号スイートの脆弱性について
A roster of TLS cipher suites weaknesses
--------------------------------------------
[問3]
SSL/TLSについての話をする上で, 基本となる暗号理論についての問題です.
以下にあげた基本的なトピック, 発展的なトピックからそれぞれ1つずつ選び, あなたの理解を, あなたの言葉で解説してください.
#### 基本 ####
* ChaCha20 / Poly1305
* RSA
* AES
* GCM
#### 発展 ####
* 格子暗号
* 電力解析攻撃
* ホワイトボックス暗号
* Multi Signature Scheme
---------------------------------------------
#### 基本 ####
ChaCha20 / Poly1305
ChaCha20 - ストリーム暗号
Poly1305 - メッセージ認証(MAC)
Poly1305 は最初 hash127という2^127-1の素数を使ってMACを計算する方法を発表していたが, 後に計算効率が良い2^130-5の素数を使ったPoly1305を発表した。
鍵の生成に対象暗号と組み合わせる必要があり, 論文ではAESと組み合わせたPoly1305-AESが使われていた.
Poly1305の仕組み上, AES以外の対象暗号とも組み合わせられる。
軽量な暗号化方式なため, スマートフォンやウェアラブル機器でも高速な処理が期待できる.
Poly1305はHMAC-SHA1の出力が20bytesになるのに対して, 16bytesと小さい.
これはつまり, RC4-SHAやAES-SHAのような古い暗号スイートを使用した際のTLSネットワークオーバーヘッドを16%削減している.
RFC7539ではPoly1305とChaCha20を組み合わせた形で仕様化された. (2015/05)
非常に簡潔なアルゴリズムで規定されておりソフトウェア処理に向いている.
ChaCha内部で暗号化処理を20ラウンド行うのでChaCha20.
Daniel Bernsteinによって開発されたストリーム暗号のSalsa20の変種として後に発表された.
構造は似ている.
Googleがこの暗号方式を推奨している.
AESハードウェアを有していないデバイスで、AES-GCMの3倍の速さで処理ができる. TLS cipher suite
ChaCha20はパディング-オラクル攻撃(例えばLucky13)に強い.
タイミング攻撃にも強い.
-タイミング攻撃
暗号化までの時間を計測することで鍵を予測する方法. サイドチャネル攻撃の一種.
ChaChaは加算剰余, XOR, ビットローテーションという単純な計算処理のみで構成される.
暗号化/複合手順
- 定数, key, block-count, nonce から64byteのストリームを作成
- ストリームに対して演算(後述)を行う
- 平文(暗号文)とXORを取り暗号化/複合する
ストリームは以下のようになっている
c1 c2 c3 c4
k1 k2 k3 k4
b1 n1 n2 n3
c : 定数
k : key
b : block-count
n : nonce
各ブロックは4bytes ( = 4 * 16 = 64 bytes)
列要素, 対角要素をそれぞれ
a, b, c, d として演算(QuarterRound)を行う
-擬似コード-
function QUATERWOUND (a, b, c, d)
a += b; d ^= a; d <<<=16
c += d; b ^= c; b <<<= 12
a += b; d ^= a; d <<<=8
c += d; b ^= c; b <<<= 7
return a, b, c, d
endfunction
QuarterRoundをそれぞれの列要素で行い計4回(つまり 1 round)
QuarterRoundをそれぞれの対角要素で行い計4回(つまり 1 round)
列QuarterRound * 4
対角QuarterRound * 4
これを1セットとして、10セット(10 + 10 = 20ラウンド)繰り返すことでChaCha20の完成
AESでのDecryptにはEncryptの逆関数を用意しないといけないのに対して, ChaCha20ではkey, nonce, ブロックカウンタが定まっていれば逆関数が必要ないためソフトウェア処理がシンプルになる.
計算が加法, XOR, ビットローテーションであることも処理がシンプルな所以である.
— Poly1305 —
ChaChaと同様、シンプルなアルゴリズムで実装されているためソフトウェア処理に向いている.
タイミング攻撃に対応した実装が必要.
2^130 - 5 の素数を法とする体で計算が行われる.
Poly1305のアルゴリズム is Simple
1. 認証するデータ(メッセージ)を16bytes長に分割し、頭に0x01を付加して17bytes長のブロックにする.
2. 16bytesに満たないブロックは0x01を付加した後に0でパディングして17bytesにそろえる.
3. それぞれのブロックを係数とした多項式を考える
C1, C2, C3, …Cn とすると
f(x) = C1*x^n + C2*x^n-1 + … Cn*x
である.
4. 16bytes長の鍵r, sを用意する.
rは128bits全てを利用せず, 一部のbitを0にして22bits分間引く.
※22bits分間引いたのは部分剰余のサイズを一定の範囲に収め、各ブロックごとの逐次計算の効率化を図るため.
5. f(r)を評価して 2^130-5 の剰余を求める
6. この値に鍵sを加えてMACデータの完成
このままだと130bitsとキリがよくない(扱いにくい)ので128bitsのメッセージ認証データとする.
— 擬似コード —
MOD = 2**130 - 5
function (coefs, r, s)
x = 0
for i, coef : enumerate(coefs[::-1])
x += coef % MOD * pow(r, i+1, MOD) % MOD
endfor
return (x + s) & 0xffffffffffffffffffffffffffffffff
endfunction
鍵r, sはChaCha20のブロックカウンタ0でのStateを求めて, 下位32bytesのうち
上位16bytesをs
下位16bytesをr
とする.
— ChaCha20-Poly1305とは —
TLSではこれらを組み合わせてAEAD(認証付き暗号)として利用する.
ChaCha20-Poly1305はTLSの暗号通信を行う際のシーケンス番号をNonceとして利用する.
この8bytesに0パディングを行い, 12bytes長にしてからMaster Secretによって生成される12bytesのWriteIVとXORをとって真のNonceとなる.
※ ChaCha20のNonceは12bytes
これによりAES-GCMで問題になったIV再利用を避けることができるので安全な実装といえる. また, IVを送信する必要がないので通信データ量の削減ができる.
AES-GCMと比較すると,
AES-NIがある場合にはGCMが高速に動くが, ARM環境などAES-NIがない場合においてはChaCha20-Poly1305を選択するのが良いと言える.
ソフトウェア処理に向いていると言える.
ChaCha20の初期カウンタ0のStateをPoly1305の鍵r, s用に使用し
カウンタ1以降で平文を暗号化していき, 最終的にMACも得る.
実装しました.
--参考--
新しいTLSの暗号方式ChaCha20-Poly1305 - ぼちぼち日記
IETF が TLS 1.3 を正式に承認 – UTM/NGFWでマルウェア・標的型攻撃対策｜ウォッチガード・テクノロジー
GoogleがTLSでの採用を提唱している共通鍵暗号方式「ChaCha」についてまとめた - sonickun.log
wolfSSLのChaCha20-Poly1305暗号スイート – wolfSSL:Blog
ご存知でしたか？wolfSSLのChaCha20とPoly1305 – wolfSSL:Blog
Google Online Security Blog: Speeding up and strengthening HTTPS connections for Chrome on Android
Google Online Security Blog: A roster of TLS cipher suites weaknesses
RSA
CTFをやっている方々にはおなじみだと思います.
公開鍵暗号の一種
充分大きな数字の素因数分解が困難であることを解読の難しさ(暗号強度)としている.
これまではキーパラメーターが1024bitsであったが, コンピュータの計算速度向上や量子コンピュータの出現により推奨されない. 現在では2048bits以上が推奨されている.
キーパラメータが1024bitsというのは, 使用される素数 p, q が1024bitsであるという意味.
二つの素数p, q
公開鍵 e <- 任意, n = p*a
秘密鍵 d
暗号文 c
平文 m
c = m^e mod n
m = c^d mod n
秘密鍵 d は phi を 法とする e の逆元
phi = (p-1)*(q-1)
e*d = 1 mod phi — (1)
-証明-
(1)を書き換えると
phi * k + 1 = e*d
c^d = m^ed = m^(phi*k) * m mod n
オイラーの定理より
a^phi(n) = 1 mod n
: ただし a, nは互いに素
c^d = 1^k * m mod n
= m
RSA運用において気をつけるべき点として,
-> 小さすぎる公開鍵eを使用しない
暗号文のe乗根を取ることで平文が得られることがある
-> 大きすぎる公開鍵eを使用しない
d < 1/3 * N^(1/4)にならないようにする
Wiener’s Attack が適用される
連分数展開による近似で秘密鍵が得られる
-> 共通のnと異なるeで暗号化をしない
Common Modulus Attack が適用される
拡張ユークリッドによる解読が可能
c1 = m^e1 mod n
c2 = m^e2 mod n
s*e1 + t*e2 = GCD(e1, e2) となる s, t を拡張ユークリッドにより求める
c1^s * c2^t = m ^ ( s*e1 + t * e1) mod n
= m ^ 1
GCD(e1, e2) = 1
-> 2つの素数p, qを近い数字にしない
etc..
純粋に暗号化するだけではRSAは*適応的選択暗号文攻撃によって攻略されてしまう.
適応的選択暗号文攻撃(Chosen Cipher-text Attack)
任意に選択した暗号文に対応する平文が得られる状況で, 目的とする暗号文に対応する平文を求める攻撃.
目的の暗号文を得た上で攻撃を行う適応的選択暗号文攻撃(CCA2)とそうでないもの(CCA1)に分類される.
そのため, RSAを暗号化に用いる場合は, 平文に適当なパディングを付加した上で暗号化し, 復号時にパディングを取り除くような手法が提案されている.
このパディング方式はPKCS #1で定められていて, RFC3447として規格化されている.
ここではPKCS#1 v1.5とOAEPの2つが定義されている.
PKCS#1のパディング方式は, ROBOT攻撃に対する脆弱性が存在したとして問題になった.
-- 参考 --
RSAに対する適応的選択暗号文攻撃とパディング方式 - ももいろテクノロジー
The ROBOT Attack - Return of Bleichenbacher's Oracle Threat
AES
Advanced Encryption Standard
DESに変わって新しい標準となる対象暗号アルゴリズム.
Rijndeal(以降AES)という暗唱暗号アルゴリズムが2000年にAESとして選定された.
現在世界中で広く使われている対象暗号アルゴリズムである.
が, 先述したChaCha20が取って代わる日も近いかもしれない.
DESと同じく, 複数のラウンドから構成されており,
1ラウンドは
SubBytes, ShiftRows, MixColumns, AddRoundKey の4つの処理を行う.
それぞれは置換, シフト, 混同, XORを行うレイヤである.
AESのブロック長は128bits(16bytes)で固定である.
1. 入力データを16bytes長に分割する
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
2. Subbytes
分割されたバイトデータそれぞれに対してS-BOXによる置換を行う.
置換にはLookup tableを参照.
3. ShiftRows
各行ごとに左シフト(ローテーション)を行う.
n行目でn-1回左シフト
線形変換
下記のようになる
1 2 3 4 : 0左シフト
6 7 8 5 : 1左シフト
11 12 9 10 : 2左シフト
16 13 14 15 : 3左シフト
4. MixColumns
各バイトに対してGF(2^8)による剰余演算を行う.
線形変換
5. AddRoundKey
ラウンドキーとXOR演算を行う.
これらの処理を鍵長に応じて複数回繰り返すと暗号化ができる.
4つのレイヤ処理を逆順に逆関数を利用して復号を行う.
AddRoundKey -> InvMixColumns -> InvShiftRows -> InvSubBytes
※ AddRoundKeyはXORをとっているだけなので, Invである必要はない.
SubBytesで利用するS-BOXや各処理の逆関数を必要とする点では, 利用コストが高いかもしれない.
AESにはAES-CBC, AES-CTR, etc.. のように, ”モード”というものがある
モードはAESに限らずブロック暗号に用いられるアルゴリズムである. なので今回は割愛.
実装してない(´･_･`)
--参考--
暗号技術入門第3版
GCM
Google Cloud Messaging for Android でも Greatest Common Divisorでもなく
Galois/Counter Modeのことだと思います(多分).
ハードウェア向き(ソフトウェア向きではなく, 軽量デバイスでは処理できない)
暗号化としてCTRモードを, 認証としてGalois modeを組み合わせたものである.
Galois Fieldにおける乗法を行なっている.
AES-GCMにおいて, IVを再利用しているというバグ(?)が見つかりやばかったらしい.
--参考--
https://eprint.iacr.org/2004/193.pdf
#### 発展 ####
格子暗号
(´･_･`)
--参考--
http://elliptic-shiho.github.io/slide/katagaitai_winter_2018.pdf
https://www.imes.boj.or.jp/research/papers/japanese/15-J-09.pdf
http://www.ieice.org/ess/sita/forum/article/2015/201510061143.pdf
http://www.iisec.ac.jp/proc/vol0006/arita14.pdf
katagaitai workshop #7 crypto ナップサック暗号と低密度攻撃
電力解析攻撃
攻撃者にとって暗号システムはもはやブラックボックスではなく, 攻撃可能で鍵の情報を得ることができる.
コンピュータは電気で動くので重い処理をすれば当然それなりに電力を消費する.
暗号化処理を行う際も負荷がかかるような演算をしたりメモリ内容を多く書き換えたりするとそれに伴って電力を消費する.
—>> 消費電力という形で情報が漏れてしまっている
暗号システムの入出力(平文/暗号文)と消費電力を解析することで他の様々な情報を得ることができる.
比較処理 : 条件分岐
乗算処理 : ハミング重み
べき乗処理 : 指数のハミング重み
メモリの書き換え
上記の処理では特に電力消費の違いが生じるため, 攻撃者にとって都合の良い情報となる.
電力解析には様々な手法があり, 以下にいくつか記述する.
・単純電力解析(Simple Power Analysis)
電力消費量を測定して処理を解析.
##スマートカードに対して実際に行われた単純電力解析の原理や測定方法##
原理
スマートカードなどのデバイスのほとんどはトランジスタで構成された論理回路からなり, ゲートに電圧が加えられた時に
電流が流れ, 電力が消費される.
回路の消費電力は演算とデータの値に関係する.
乗算では0を書き込むよりも1を書き込む方が消費電力が大きくなり, また乗法演算と平方演算では異なる電力を消費する.
デバイスの消費電力の変化を観察することで解析ができる.
このように消費電力の変化を直接解析に用いる方法を単純電力解析(SPA)と呼ぶ.
測定
デバイスと電源(or 接地)との間に抵抗を直列につなぎ, 抵抗を流れる電流から求めることができる.
・差分電力解析(Differential Power Analysis)
電力消費量の差分の統計から秘密鍵を解析.
原理
デバイスの消費電力は一般に演算内容と演算に用いられている秘密情報に依存する. しかしこれらの内容に依存した消費電力の変化が小さいため, 測定誤差やノイズなどから変化を見分けるのは困難.
“””大量の測定値の平均をとって測定誤差やノイズなどの影響を小さくし, 全データの平均値との差分を取ることで演算プロセスによる電力消費の影響を除いて, 秘密情報による消費電力の変化だけを取り出す”””
という方法が提案された.
・相関電力解析(Correlation Power Analysis)
コンピュータのデータはメモリやレジスタといった記憶装置に保存される.
メモリやレジスタが内部に電荷を保持しているかどうかで0と1とを判断している.
電荷を保持しているので,
0→1, 1→0
といった処理(ビット反転)をすると電力を大きく消費してしまう.
当然1回のデータ変更で反転するビット数が多いほど消費電力も大きくなる.
コンピュータシステムと同様に多くの暗号システムでも, さまざまな入力が記憶装置に
処理され, 格納され, 処理され… を繰り返し, 最終的に暗号文を出力する.
この間, 記憶装置(メモリやレジスタ)では各処理ごとに入力と出力の差分(ハミング距離)だけビットを反転させる.
このときハミング距離が小さければ消費電力も小さく, 大きくなれば消費電力もまた大きくなる.
つまり, 処理の入出力のハミング距離と消費電力とは相関関係があると考えられる.
入出力を記録し, それに対応する消費電力変化を解析することで秘密情報を得られる.
これらの攻撃, 電力解析をされないよう, ソフトウェア側で制御する必要がある.
そもそも解析されない(攻撃者にとって有益な情報を漏らさない)ような設計にしよう!! というのが次トピックのホワイトボックス暗号.
--参考--
↓AESやDESだけでなくRSA, 楕円曲線暗号に対する電力解析についても説明されている
ホワイトボックス暗号
White Box CryptographyでWBCと表記されることもある.
従来の暗号方式は, 攻撃者が暗号鍵にアクセスできず平文と暗号文にアクセスできると仮定している”ブラックボックス”であることが前提とされていた.
平文/暗号文以外に漏れてしまった情報から攻撃を行う手法が開発され, 攻撃者はこのブラックボックス内で使用される秘密鍵を入手することが可能になった.
つまり完全なブラックではなくなってしまい “グレー” と例えられている.
ブラックボックス
利用者(や攻撃者)が得られる情報は平文と暗号文に限られており,
暗号化の仕組みや内部情報を知ることができないことを仮定している.
グレーボックス
攻撃者が暗号鍵に部分的にアクセスができる状態.
サイドチャネル情報が流出している状態.
タイミング情報, 電力消費情報を観測することで鍵に関する情報を得ることができる.
現在明らかになっている攻撃手法により暗号鍵(の一部)を明らかにすることが可能になっている.
ブラックボックスと思われている暗号方式もすべからく安全というわけではない.
ホワイトボックス
ブラックボックスとは対象的に, ホワイトボックスは完全な可視性を提供している.
ホワイトボックス暗号方式は暗号化を実行するマシンを攻撃者が自由に制御できる場合でも鍵の情報が漏れないように実装される.
ホワイトボックスであるが故の脅威もあり, バイナリを見たり暗号アルゴリズムにアクセスしたり, 実行環境を自由に制御できることも可能.
脅威に対抗するための解決策としてWBCが存在する.
アルゴリズムの実装は解読が極めて困難な数学的操作に基づいている.
アルゴリズム, 平文, 暗号文, など攻撃者が様々な情報を入手していても解読を困難にするのがWBC
AESよりも難読化されるので解析が難しくなる.
・power analysis
処理時のコンピューターの消費電力を記録
相関電力解析により鍵を取り出すことが可能
・fault analysis
入力の一部を変えてみて, 出力がどのように変化するか.
差分から鍵を取り出すことが可能
などがある.
これらの攻撃が成功しないように,
IVを固定(or 再利用)しない
-> AESであればStateが同じになってしまうので電力解析や差分解析によって鍵が漏洩する可能性がある.
セキュアとされている公開鍵アルゴリズムを利用する
より安全なWBCのために
-> 毎回鍵を変更する
といった, ソフトウェア側での対策が必要とされる.
暗号アルゴリズムや平文/暗号文が攻撃者に知られているオープンな状態でも
・電力解析や差分解析をさせない
・鍵(の一部)を取得させない
というのがWBCの課題(?)となる.
前トピック(電力解析)と関連がある話題.
--参考--
http://support.safenet-inc.jp/srm/tech_note/wp/Web_WP_Whitebox_Cryptography.pdf
https://www.slideshare.net/linecorp/practical-attacks-on-commercial-whitebox-cryptography-solutions
Multi Signature Scheme
検索してヒットするのはBitcoinをはじめとするCryptoCurrencyに関連するMulti signature Addressくらい
(´･_･`)
以上.
