16
第4回Web技術勉強会 暗号技術編その2 田実

第4回web技術勉強会 暗号技術編その2

Embed Size (px)

Citation preview

Page 1: 第4回web技術勉強会 暗号技術編その2

第4回Web技術勉強会暗号技術編その2

田実 誠

Page 2: 第4回web技術勉強会 暗号技術編その2

• 公開鍵暗号方式• RSA• Man In The Middle

• ハイブリッド暗号• 一方向ハッシュ

• 弱衝突耐性と強衝突耐性• メッセージ認証コード

アジェンダ

Page 3: 第4回web技術勉強会 暗号技術編その2

公開鍵暗号方式(非対称暗号)• 秘密鍵と公開鍵の2種類の鍵ペアを利用する。

• 公開鍵で暗号化したものは秘密鍵でのみ復号化できる。※逆に秘密鍵で暗号化したものは公開鍵でのみ復号化出来るという対称性を持つためデジタル署名にも利用される。(アルゴリズムによっては必ずしも対称ではない)

• 鍵の数が少なくて済む(クライアント数分だけ鍵ペアが有れば良い)

• アルゴリズムとしてはRSA, ElGamal, Rabin, 楕円曲線暗号

• 鍵の配送問題が発生しない。→復号化するためには秘密鍵が必要であり暗号化のための公開鍵が流出しても問題ない

• 共通鍵暗号方式と比べて、計算コストが高い

Page 4: 第4回web技術勉強会 暗号技術編その2

RSA暗号文 = 平文E mod N

平文 = 暗号文D mod N

平文/暗号文を表す数をE/D乗して剰余計算するだけ!

→EとNの組み合わせが公開鍵、DとNの組み合わせが秘密鍵

a = bytes_to_long(b64d("nOcQOvHV8rc-hcfP_RmxMGjyVlruSLeFXTojYcbixaAH36scUejjaws31orUjmYqB5isE9ntdsL4DnsdP_MDJ2mtYD2FIh8tBkJjgXitjdcDclrwELAx846wBIlSES8wR6czpdJZfSwhL_92EGpDH6z7lKEClqhDlbtZ-yFKFj9BQRwaEXWV7uuq23gxXOqyEN0WXl3ZJPgsodCnlXRn9y_r5CNV9V4wvzXGlJhT3Nv_N_Z5XNZIjZnHdCuE_itT4a1xENEEds7Jjg5mRTlVFzYv5iQtBo7jdY5ogMTgKPmRh6hYuqLeki3AOAUff1AGaN9TZH60UxwTw03-DQJL5C2SuC_vM5KIWxZxQniubfegUCBXpJSAJbLt8zSFztTcrLS4-wgUHo1A8TDNaO28_KsBUTWsrieOr3NfCn4bPNb7t8G90U60lW0GIhEda3fNYnV0WWpZVO1jCRNy_JYUs3ECo0E1ZQJZD72Dm6UjiuH7eR3ZgNKR9tlLNdyZSpZUZPErLrXJ90d5XbmJYvRX9r93z6GQqOv5FQy1JhatwefxhKdyhkDEHsqELO0XDqnDnmgxkEEU-lHYSVGz-iDlUZOUYTTCtxsPDmBIXOMuwp0UydJphO36qRQaDyEjHNsYKLj5KVvjDHS8Gw1FhbFvsoUrBHre4hLY9Pa5meatV_k"))

640106726278319126659431929858707265548495638794335271214074859616932461479258165446754843680716129502812427488999385422927101954586353742178769013480650233043231959739449947342487907619182512812761980563585694694149617890913166780258201684892570157411848511348332396253035684855913691742013947790025083603161078930452379151334805843557358109304228135658809043429555085027115536160671742230209287726620709092318764864717241500004574771499745232402139883605323620381924110905205533594055386294131248827391199687450065674026697169446850516777724130292682756588435426866604648240423661007196113589546951520209466625667299709688533427796289125959403445502037295792693107750611735068842744404199734827982093138118631982220297293741870750640027191603742769821684226255109249941744057642859529189790851524288601799354534475954124563870778397663995929186592708290563808347561115454553411013335814482585741565674787853837709938984569870186485209384599990531943343794499603741449568950374437886156063532129784055978342195044515419517659212489215579210755964949367350100185206763817272023305071449788232867917449585121347149323337821415633455025489119275620620193644519028790277690042048623166572492795617378443748964613269463470767474438133753

Page 5: 第4回web技術勉強会 暗号技術編その2

RSAの鍵のパラメータの求め方1. N = p * q (p, qは素数)となるようなp, q(大きい値)の組み合わせを用意する

2. p-1, q-1の最小公倍数を求める(L = lcm(p-1, q-1))

3. EとLの最小公約数が1 (互いに素)となるようなEを求める

4. E * D mod L = 1となるようなDを求める

• pとqの組み合わせが漏洩するとDが特定される→大きなNの素因数分解を高速にできる方法が発見されたらRSAは解読できる

Page 6: 第4回web技術勉強会 暗号技術編その2

パラメータ利用例:JWKJson Web Key: デジタル署名を検証するための鍵を公開するための仕組みhttps://tools.ietf.org/html/rfc7517

• Salesforce (OpenID Connect)https://login.salesforce.com/id/keys

• Googlehttps://www.googleapis.com/oauth2/v2/certs

def get_rsa_publickey(jwt_header):"""https://{sfdcドメイン}/id/keysから公開鍵を取得する。"""kid = json.loads(b64d(jwt_header).decode())["kid"]req = urllib.request.Request(url=BASE_URL + "/id/keys") res = urllib.request.urlopen(req)jsonMap = json.loads(res.read().decode())

modulus = b64_to_long(target_key["n"])exponent = b64_to_long(target_key["e"])return RSA.construct((modulus, exponent))

Page 7: 第4回web技術勉強会 暗号技術編その2

Man In The Middle (MITM)• 中間者攻撃と言われる、送信者と受信者の間を中継して盗聴する

②攻撃者の公開鍵で暗号化

①攻撃者の公開鍵を「受信者の公開鍵」として渡す

④受信者の公開鍵で暗号化

③攻撃者の秘密鍵で復号化

⑤受信者の秘密鍵で復号化し、改竄されたメッセージを受け取る

• 問題は「受信者の公開鍵」が「攻撃者の公開鍵」にすり替わっている(なりすまし)こと→このなりすましを防ぐ手段が「デジタル証明書」(=公開鍵が正しいことを証明する仕組み)

※ちなみにMITMはSSL/TLS等で暗号化された通信をデバッグ用途で復号化することにも利用できるため、悪いことばかりではない。(Fiddler, Charles, mitmproxy)

攻撃者 受信者送信者

Page 8: 第4回web技術勉強会 暗号技術編その2

ハイブリッド暗号• 対称暗号方式は高速に暗号化/復号化できるが、鍵の配送問題がある

• 公開鍵暗号方式は鍵の配送問題はクリアしているが、暗号化/復号化速度に難がある

→対称暗号と公開鍵暗号を組み合わせて短所を補う=ハイブリット暗号

【送信側】

1. メッセージは一時的な共通鍵(セッション鍵)を使って、対称暗号で暗号化

2. セッション鍵を公開鍵で暗号化

3. 暗号化したセッション鍵と暗号化したメッセージを送信

【受信側】

1. 暗号化したセッション鍵と暗号化したメッセージを受信

2. 暗号化されたセッション鍵を秘密鍵で復号化

3. 暗号化したメッセージを対称暗号で復号化

Page 9: 第4回web技術勉強会 暗号技術編その2

一方向ハッシュ• 任意のデータが「本物であるかどうか」を担保する性質(正真性)を高めるための技術

• ソフトウェアの改竄検知

• パスワード+ソルトによる暗号化(DBにパスワードをそのまま保存しない暗号技術)

• メッセージ認証コード

• デジタル署名

• 擬似乱数生成器

• ワンタイムパスワード

• あるデータを別の短い値(固定値)に変換する処理→”データの指紋を取る“ことに相当する

• 入力を「メッセージ」、出力を「ハッシュ値」( 「メッセージダイジェスト」「フィンガープリント」 )と呼ぶ

• アルゴリズムとしてはMD5、SHA-1、SHA-2等※ただし、MD5は強衝突耐性が破られているため、安全ではない。SHA-1もセキュリティ欠陥の可能性がある。

• 一方向(不可逆)なため、生成した文字列から元の文字列を予測することは不可能。

Page 10: 第4回web技術勉強会 暗号技術編その2

弱衝突耐性、強衝突耐性• メッセージが異なればハッシュ値も異なるような性質を持たなければならない→2つの異なるメッセージが同じハッシュ値を持つことを、「衝突」と呼ぶ→一方向ハッシュ関数は「弱衝突耐性」「強衝突耐性」を持つ必要がある

• 弱衝突耐性→あるメッセージのハッシュ値が与えられた時、そのハッシュ値を持つ別のメッセージを見つけ出すことが困難

• 強衝突耐性→ハッシュ値が一致するような、異なる2つのメッセージを見つけ出すことが非常に困難。

Page 11: 第4回web技術勉強会 暗号技術編その2

一方向ハッシュ利用例:ファイルダウンロード

• https://www.apachefriends.org/jp/download.html• https://www.openoffice.org/download/checksums/3.4.0_checksums.html

ダウンロードしたファイルの中身が正しいかどうか(改竄されていないか)を検証する仕組み

Page 12: 第4回web技術勉強会 暗号技術編その2

メッセージ認証コード• Message Authentication Code(MAC)と呼ばれるメッセージの認証を行う技術→「メッセージが正しい送信者からのものである」性質(=なりすましを防止する)

• IPSec

• SSL/TLS

• AWSのAPIの認証方式(Signature Version4など)

• 鍵(共有)に依存した一方向ハッシュ

② メッセージ+メッセージ認証コードを送信

① 共有された鍵を使って、メッセージに対するメッセージ認証コードを生成

③ 共有された鍵を使って受信したメッセージのメッセージ認証コードを生成④ 受信したメッセージ認証コードと③で生成したコードを比較→一致すれば認証成功

受信者送信者

Page 13: 第4回web技術勉強会 暗号技術編その2

メッセージ認証コード• 一方向ハッシュ関数(SHA-1, MD5)を使うこともできるし(HMAC)、ブロック暗号を使って実現することも可能

• 一方向ハッシュ関数を使うとHMAC-SHA1, HMAC-MD5というアルゴリズムになる

• ブロック暗号を使う場合はCBCモードで暗号化して、最後のブロックだけメッセージ認証コードとして利用する

• CBC-MAC, CMAC, PMAC

• 送信者と受信者が鍵を共有するため、「鍵配送問題」が発生する

• 再生攻撃による「なりすまし」が可能

• シーケンス番号、タイムスタンプ、ノンスを使って攻撃を防ぐ→メッセージが少しでも異なればメッセージ認証コードも変わる

• 第三者が認証を証明することが出来ない→第三者が認証を証明するためには、第三者が同じ鍵を持つ必要があり、その第三者がメッセージ認証コードを作成できてしまう。

• 否認防止ができない→受信者も同じ鍵を持つため、メッセージを作成したのは受信者かもしれない。

Page 14: 第4回web技術勉強会 暗号技術編その2

HMACの例:Signature Version4

CanonicalRequest =HTTPRequestMethod + '¥n' +CanonicalURI + '¥n' +CanonicalQueryString + '¥n' +CanonicalHeaders + '¥n' +SignedHeaders + '¥n' +

HexEncode(Hash(RequestPayload))

StringToSign =Algorithm + '¥n' +RequestDate + '¥n' +CredentialScope + '¥n' +HashedCanonicalRequest))

kSecret = Your AWS Secret Access KeykDate = HMAC("AWS4" + kSecret, Date)kRegion = HMAC(kDate, Region)kService = HMAC(kRegion, Service)kSigning = HMAC(kService, "aws4_request")

HexEncode(HMAC(derived-signing-key, string-to-sign))

Authorization: algorithm Credential=access key ID/credential scope, SignedHeaders=SignedHeaders, Signature=signature

Page 15: 第4回web技術勉強会 暗号技術編その2

HMACの例:HOTP/TOTP

出典: http://www.atmarkit.co.jp/ait/articles/1310/17/news003_2.html

HOTP/TOTP: ワンタイムパスワード生成の方式(二段階認証で利用される)• HMAC-Based One-time Password(OTPの生成回数をメッセージとする)• Time-based One-time Password(時刻をメッセージとする)

Page 16: 第4回web技術勉強会 暗号技術編その2

• 公開鍵方式は秘密鍵、公開鍵の鍵ペアを利用し、公開鍵で暗号化、秘密鍵で復号化する方式

• 秘密鍵は生成元側で保持し、公開鍵は相手に渡すことにより鍵の配送問題をクリアしている

• 一方向ハッシュによって任意のサイズのデータ(メッセージ)を固定長の値(ハッシュ値)に変換でき、それによりメッセージの正真性を高める

• メッセージ認証コードによってなりすましを防止することができる

まとめ