強力な暗号化

強力な暗号または暗号的に強いとは、正しく使用すれば、政府機関を含むあらゆる盗聴者に対して非常に高い（通常は突破不可能な）レベルの保護を提供する暗号アルゴリズムを指す一般的な用語です。 [ 1 ]強力な暗号と（破られやすい）弱い暗号の境界線は、ハードウェアや暗号解読技術の進歩により常に変化しているため、明確に定義されていません。[ 2 ]これらの進歩により、かつてはNSAだけが利用できた機能が、熟練した個人の手に届くようになりました。[ 3 ]そのため、実際には暗号セキュリティには2つのレベル、「妹がファイルを読むことを防ぐ暗号と、主要政府によるファイルを読むことを防ぐ暗号」（ブルース・シュナイアー）しかありません。[ 2 ]

強力な暗号化アルゴリズムは、高いセキュリティ強度を持ち、実用上は通常、鍵のビット数で定義されます。たとえば、米国政府は、暗号化の輸出管理を扱う際に、1999年の時点で、鍵長が56ビットを超える対称暗号化アルゴリズムまたはその公開鍵相当物[ 4 ]の実装は強力であるとみなし、したがって、輸出ライセンスの対象になる可能性があります。[ 5 ]アルゴリズムが強力であるためには、十分に長い鍵を持ち、既知の数学的な弱点がない必要があります。これらの弱点を悪用すると、実質的に鍵のサイズが小さくなるためです。21世紀初頭、強力な対称暗号化アルゴリズムの一般的なセキュリティ強度は128ビットです（これよりわずかに低い値でも強力になり得ますが、通常、より小さな鍵サイズを使用することによる技術的な利点はほとんどありません）。[ 5 ]

暗号方式の攻撃耐性を証明することは複雑な作業であり、広範なテストとレビュー、できれば公開フォーラムでの検証が必要です。優れたアルゴリズムとプロトコルは必要ですが（同様に、強固な建物を建設するには優れた材料が必要です）、優れたシステム設計と実装も必要です。「強力なアルゴリズムとプロトコルを用いても、暗号的に弱いシステムを構築することは可能です」（建設において優れた材料を使用したからといって、強固な構造が保証されるわけではないのと同じです）。現実の多くのシステムは、強力な暗号が適切に使用されていない場合、例えばランダムナンスが再利用されるなど、脆弱であることが判明しています[ 6 ]。攻撃が成功する際には、アルゴリズムが全く関与していない場合もあります。例えば、鍵がパスワードから生成される場合、弱いパスワードの推測は容易であり、暗号プリミティブの強度に依存しません[ 7 ] 。例えば、パスワードやハードウェアトークンを同僚と共有するなどして、ユーザーが全体像の中で最も弱いリンクとなる可能性があります[ 8 ] 。

背景

強力な暗号化には多大な費用が必要だったため、当初は政府や軍事機関のみでの使用に限られていた。[ 9 ] 20世紀半ばまでは、暗号化のプロセスには多くの人的労力が必要で、（解読を妨げる）エラーが非常に多かったため、暗号化できたのは書かれた情報のごく一部だけだった。[ 10 ]特に米国政府は、1960年代まで米国における暗号化の開発と使用の独占を維持することができた。[ 11 ] 1970年代には、強力なコンピュータが利用できるようになり、非機密扱いの研究上のブレークスルー（データ暗号化標準、ディフィー・ヘルマンおよびRSAアルゴリズム）により、強力な暗号化が民間でも利用できるようになる。[ 12 ] 1990年代半ばには、強力な暗号化に関する知識とツールが世界中で急増した。[ 12 ] 21世紀までには技術的な制限はなくなったが、通信の大部分は依然として暗号化されていない。[ 10 ]同時に、強力な暗号システムの構築と運用にかかるコストは、弱い暗号システムの場合とほぼ同じになった。[ 13 ]

コンピュータの使用は暗号解読のプロセスを一変させました。ブレッチリー・パークの「コロッサス」が有名です。しかし、デジタルコンピュータと電子機器の発達が暗号解読に貢献したのと同様に、はるかに複雑な暗号も可能になりました。質の高い暗号の使用は非常に効率的ですが、それを解読するには桁違いに膨大な労力が必要になります。そのため、暗号解読は非常に非効率的で非現実的になり、事実上不可能になっています。

暗号的に強力なアルゴリズム

「暗号的に強い」という用語は、暗号化アルゴリズムを説明する際によく用いられ、他のアルゴリズム（つまり暗号的に弱いアルゴリズム）と比較して、攻撃に対する耐性が高いことを意味します。しかし、ハッシュや一意の識別子、ファイル名の作成アルゴリズムを説明する際にも用いられます。例えば、Microsoft .NETランタイムライブラリ関数Path.GetRandomFileNameの説明を参照してください。[ 14 ]この場合、この用語は「推測が困難」という意味になります。

暗号化アルゴリズムは、解読不可能（その場合、アルゴリズムは可能な限り最も強力）であることが意図されていますが、解読可能な場合（その場合、アルゴリズムは可能な限り最も弱い）もあるため、慣用句が示唆するような強度の連続性は原理的に存在しません。アルゴリズムAはアルゴリズムBよりも強く、アルゴリズムBはアルゴリズムCよりも強く、といった具合です。暗号解読攻撃には多くの種類があり、特定のアルゴリズムであっても、ある攻撃を用いる場合と他の攻撃を用いる場合では、解読に要する作業量が異なる可能性が高いため、状況はさらに複雑になり、単一の強度指標にまとめることは困難です。

解読不可能な暗号システムは、ワンタイムパッドという唯一のものが知られています。しかし、ワンタイムパッドを盗まれることなく交換することが困難なため、一般的には使用できません。そのため、あらゆる暗号化アルゴリズムは、完璧なアルゴリズムであるワンタイムパッドと比較することができます。

この用語が（ゆるく）使用される通常の意味では、特定の攻撃、ブルートフォース鍵探索について言及するものであり、特にこの分野の初心者への説明において用いられます。確かに、この攻撃（鍵がランダムに選択されたと常に仮定）では、使用される鍵の長さに応じて耐性が連続的に変化します。しかし、それでも2つの大きな問題があります。多くのアルゴリズムでは、異なるタイミングで異なる長さの鍵を使用でき、どのアルゴリズムでも可能な限り完全な鍵長を使用できない場合があります。したがって、BlowfishとRC5は、複数の鍵長を明示的に考慮して設計されたブロック暗号アルゴリズムであり、したがって、ブルートフォース鍵探索に関して特に強力であるとは言えません。さらに、米国の輸出規制では、輸出可能な暗号製品の鍵長が制限されており、1980年代と1990年代には（例えば、Lotus Notesの輸出承認の有名なケース）、部分的な鍵のみが使用されたため、それらの（輸出）バージョンのブルートフォース攻撃に対する「強度」が低下しました。ほぼ同じことが米国以外でも起こりました。たとえば、GSM携帯電話規格の複数の暗号化アルゴリズムの場合です。

この用語は、あるアルゴリズムが暗号技術や情報セキュリティにおける特定のタスクに適しているだけでなく、暗号解読にも耐性があり、セキュリティ上の弱点がないか、あるいは少ないことを表すために一般的に使用されます。タスクは多岐にわたり、例えば以下のようなものが挙げられます。

暗号的に強力であるということは、記述された方法がある程度成熟しており、理論上および／または実践上、様々な種類の体系的な攻撃に対する使用が承認されていることを意味するように思われます。実際、その方法は、伝送される情報（およびその背後にあるもの）を有用な期間保護するのに十分な期間、それらの攻撃に耐えられることを意味します。しかし、この分野の複雑さと繊細さゆえに、どちらもほとんどの場合当てはまりません。そのような保証は実際には得られないため、言葉で強固であるかのように示唆することは、一般的に誤解を招くことになります。

進歩（例えば、暗号解読理論や単に手頃なコンピュータ容量など）により、アルゴリズムに対する何らかの攻撃方法を成功させるために必要な労力が軽減される可能性があるため、不確実性は常に存在します。

さらに、暗号アルゴリズムを実際に使用するには、暗号システムにカプセル化する必要がありますが、そうすることで、アルゴリズムの欠陥に起因しない脆弱性がしばしば生じます。例えば、基本的にすべてのアルゴリズムは鍵のランダム選択を必要としますが、そのような鍵を提供しない暗号システムは、使用される暗号化アルゴリズムの攻撃耐性に関わらず、攻撃を受ける可能性があります。

暗号化の広範な使用は監視のコストを増大させるため、政府の政策は強力な暗号の使用を規制することを目指している。[ 15 ] 2000年代には、強力な暗号化を使用せず、要求されたデータを政府に提供しないグローバルソーシャルメディアプラットフォームを通過する通信の割合が増加し続けたため、監視能力に対する暗号化の効果は制限された。[ 16 ]マーフィーは、急速に進化する技術に追従できるほど広い政府の権限と、国民や監督機関が法律の将来の使用を理解できるほど狭い権限との間でバランスを取る必要があると述べている。[ 17 ]

アメリカ合衆国

暗号技術の利用可能性の拡大に対する米国政府の当初の対応は、暗号研究を原子力研究と同様に扱い、「生まれながらの機密」とみなし、研究成果の発信を政府が法的に規制することだった。しかし、これはすぐに不可能であることが判明し、その取り組みは展開（輸出。米国内での暗号技術の展開禁止は真剣に検討されていなかったため）の規制へと転換された。[ 18 ]

米国の輸出管理は歴史的に2つの方法を採用している。[ 19 ]

  • 軍需品（「軍需品」と表記されているが、実際には米国軍需品リストに掲載されている品目はこの言葉の一般的な意味とは一致しない）。軍需品の輸出は国務省によって管理されている。軍需品に対する規制は非常に厳しく、個別の輸出許可証には製品と実際の顧客が明記されている。
  • 軍民両用物品（「コモディティ」）は、過度な事務手続きなしに商業的に入手可能である必要があるため、仕向地によっては民間顧客への販売について広範な許可が与えられる場合があります。軍民両用物品のライセンスは商務省が発行します。軍需品リストからコモディティへの変更手続きは国務省が担当します。

暗号技術の元々の用途はほぼ軍事目的であったため、軍需品リストに分類された。民生用途の増加に伴い、軍需品としての暗号技術は暗号の強度によって定義されるようになり、強力な暗号化技術は銃器と同様に軍需品として扱われるようになった（小火器は軍需品であり、大砲は純粋に軍事的価値がある）。[ 20 ]この分類には明らかな欠点があった。大手銀行は軍事施設と同じくらいシステム的に重要であり、[ 20 ]強力な暗号コードの公開を制限することは憲法修正第一条に反するため、1993年にクリッパーチップ（米国政府が特別な復号鍵をエスクローで保管）で実験を行った後、1996年にほぼすべての暗号品目が商務省に移管された。[ 21 ]

欧州連合

EUの立場は、米国と比較して、常にプライバシー重視の姿勢をとってきました。特に、EUは1997年という早い時期に鍵保管制度の構想を拒否していました。欧州連合サイバーセキュリティ機関（ENISA）は、バックドアは正当な監視には効果的ではないものの、デジタルセキュリティ全般にとって大きな危険をもたらすとの見解を示しています。[ 15 ]

ファイブアイズ

ファイブアイズ（ブレグジット後）は、セキュリティとプライバシーの問題に関して類似した見解を持つ国々のグループです。このグループは、合法的な傍受に関する世界的な議題を主導するのに十分な影響力を持つ可能性があります。しかし、このグループの取り組みは完全には連携していません。例えば、2019年にFacebookがエンドツーエンド暗号化を実装しないよう求めた要求は、カナダとニュージーランドのどちらからも支持されず、規制には至りませんでした。[ 17 ]

ロシア

1990年代のロシア大統領と政府は、政府機関による未認証の暗号システムの使用を正式に禁止する法令をいくつか発布した。1995年の大統領令では、適切なライセンスを持たない個人による暗号システムの製造および販売を禁止しようとしたが、1993年のロシア憲法に矛盾する疑いがあり、それ自体が法律ではなかったため、まったく施行されなかった。[ 22 ] [ 23 ] [ 24 ] [注 1 ] 2012年に発行された法令第313号は、以前の法令をさらに修正し、いくつかの制限を宣言しているにもかかわらず、暗号システムを組み込んだ製品の製造および配布を許可し、ライセンスを必要としないようになった。[ 25 ] [ 26 ]フランスはこの分野でかなり厳しい規制を持っていたが、近年緩和している。

例

強い

  • PGPは一般的に強力な暗号化技術の一例として考えられており、多くの主要なオペレーティングシステムと様々なハードウェアプラットフォームで動作するバージョンが存在します。PGP操作のオープンソース標準はOpenPGPであ​​り、GnuPGはFSFによるこの標準の実装です。しかし、従来のPGPのIDEA署名鍵は64ビットしかないため、衝突攻撃に対する耐性はもはやありません。そのため、OpenPGPではSHA-2ハッシュ関数とAES暗号化を使用しています。
  • AESアルゴリズムは、公開され、多数のテストを含む長期間にわたる選択プロセスで選択されたため、強力であると考えられています。
  • 楕円曲線暗号は、グラフィカルな幾何学関数に基づいた別のシステムです。
  • インターネット取引のセキュリティ確保に使用されているTLSプロトコルの最新バージョン（バージョン1.3）は、一般的に強力であると考えられています。以前のバージョンには、 POODLEなどの実証済みの攻撃を含む複数の脆弱性が存在しています。さらに悪いことに、一部の暗号スイートは、1996年以前の米国規制下での輸出を可能にするために、40ビットの有効鍵を使用するように意図的に弱体化されています。

弱い

暗号的に強力ではないと見なされる例には次のようなものがあります。

  • DESは、56 ビットのキーを使用して徹底的な検索による攻撃を可能にします。
  • トリプルDES（3DES / EDE3-DES）は「SWEET32バースデー攻撃」の対象となる可能性がある[ 27 ]
  • 設計上の欠陥により、さまざまな攻撃を受ける可能性のあるWired Equivalent Privacy 。
  • SSL v2およびv3。TLS 1.0およびTLS 1.1も、設計上依然として存在する不可逆的な欠陥のため、また、暗号に楕円ハンドシェイク（EC）が提供されず、最新の暗号化技術やCCM/GCM暗号モードが利用できないため、現在では非推奨となっています[RFC7525参照]。TLS1.xは、PCIDSS 3.2によって、Webフロントエンドにおける商用ビジネス/銀行業務の実装において廃止が発表されています。TLS1.2とTLS 1.3のみが許可され、推奨されており、最新の暗号、ハンドシェイク、暗号モードのみを使用する必要があります。
  • MD5およびSHA-1ハッシュ関数は、衝突攻撃の影響を受けなくなりました。
  • RC4ストリーム暗号。
  • ほとんどのDVD-Videoディスクの暗号化に使用される40 ビットのコンテンツ スクランブル システム。
  • ほぼすべての古典的な暗号。
  • エニグマ暗号機などのほとんどの回転式暗号。
  • DHE/EDHEは、サーバー上で既知のデフォルトの素数値を使用/再利用する場合、推測可能/弱い

注記

  1. ^ここで提供されている情報源はロシア語です。英語で書かれた情報源が不足している問題を緩和するため、情報源は政府の公式文書を用いて引用されています。

参考文献

  1. ^ヴァーグル2015、121ページ。
  2. ^ a b Vagle 2015、p.113。
  3. ^レヴィ、スティーブン（1994年7月12日）「クリッパーチップの戦い」ニューヨーク・タイムズ・マガジン、pp.44-51  。
  4. ^ 「暗号化および輸出管理規則（EAR）」bis.doc.gov、産業安全保障局。2023年6月24日閲覧。
  5. ^ a bラインホールド 1999、3ページ。
  6. ^シュナイアー 1998、2ページ。
  7. ^シュナイアー 1998、3ページ。
  8. ^シュナイアー 1998、4ページ。
  9. ^ヴァーグル2015、110ページ。
  10. ^ a bディフィー＆ランドウ 2007年、725ページ。
  11. ^ヴァーグル2015、109ページ。
  12. ^ a b Vagle 2015、p. 119。
  13. ^ディフィー＆ランドウ 2007年、731ページ。
  14. ^ Path.GetRandomFileName メソッド (System.IO)、Microsoft
  15. ^ a b Riebe et al. 2022、p.42。
  16. ^ Riebe et al. 2022、58頁。
  17. ^ a bマーフィー 2020 .
  18. ^ディフィー＆ランドウ 2007年、726ページ。
  19. ^ディフィー＆ランドウ 2007年、727ページ。
  20. ^ a bディフィー＆ランドウ 2007年、728ページ。
  21. ^ディフィー＆ランドウ 2007年、730ページ。
  22. ^ Farber, Dave (1995-04-06). 「ロシアにおける暗号禁止（fwd）[次へ .. djf]」 . 2011年2月14日閲覧。
  23. ^アンティポフ、アレクサンダー (1970-01-01)。「Пресловутый указ №334 о запрете криптографии」。www.securitylab.ru (ロシア語) 。2020年9月21日に取得。
  24. ^ “Указ Президента Российской Федерации от 03.04.1995 г. № 334” . Президент России (ロシア語) 。2020年9月21日に取得。
  25. ^ "Положение о лицензировании деятельности по разработке, производству, распространению зифровальных средств и 「」。Российская газета (ロシア語) 。2020年9月21日に取得。
  26. ^ "Миф №49 "В России запрещено использовать несертифициров​​анные средства зифрования"「 .bankir.ru （ロシア語） 。 2020年9月21日閲覧。
  27. ^セキュリティ速報：トリプルDES暗号に影響を与えるSweet32の脆弱性。IBMセキュリティ速報、2016年。

出典

参照

「 https://en.wikipedia.org/w/index.php?title=Strong_cryptography&oldid=1274338133」より取得