
はじめに
暗号技術と聞くと、難しそうに感じるかもしれませんが、実は私たちの身近なところで使われています。たとえば、インターネットでの通信やオンラインショッピングの決済など、私たちの生活を支える多くの場面で暗号技術が活躍しています。この記事では、そんな暗号技術の基本から、電子政府推奨暗号リストの重要性までを解説していきます。また、本記事では執筆時点(2025年1月)の暗号リストを載せております。最新の情報とは異なる場合がありますのでご了承ください。
CRYPTREC暗号リスト
電子政府推奨暗号リストはCRYPTREC ⧉(クリプトレック)が出している、CRYPTREC暗号リストの内の1つです。他にも「推奨候補暗号リスト」や「運用監視暗号リスト」と合わせて、電子政府推奨暗号リストを含めた3つのリストでCRYPTREC暗号リストは構成されています。ちなみに、電子政府における調達のために参照すべき暗号のリストというのが正式な名称です。
CRYPTRECはCryptography Research and Evaluation Committeesの略であり、電子政府推奨暗号の安全性を評価・監視し、暗号技術の適切な実装法・運用法を調査・検討するプロジェクトです。国が目指す世界最先端のIT国家を構築するには、基盤となる電子政府のセキュリティを確保する必要があります。そのため、安全性に優れた暗号技術を利用することが不可欠です。そこで、安全性及び実装性に優れると判断された暗号技術をリスト化するプロジェクトが2000年度に組織化され、現在のデジタル庁、総務省、経済産業省、国立研究開発法人情報通信研究機構(NICT)及び独立行政法人情報処理推進機構(IPA)などで構成されています。
小改訂を除いて10年程度の運用を想定して策定されており、大きな改訂も10年周期で行われ、今回掲載する最新の暗号リストも2023年に改訂されたものになっています。しかし、安全性の維持が困難(危殆化した)と判断された場合は、随時推奨から外されたり、リストから除外されるようになっています。
では、その3つのリストについて説明します。
電子政府推奨暗号リスト
CRYPTRECが安全性と実装性能を確認した暗号技術のうち、市場で利用実績が十分にあるか、今後の普及が見込まれるものを対象とし、その利用を推奨するリストを電子政府推奨暗号リストと呼びます。現在流行している暗号技術リストということです。RSAやAESは聞いたことがあるかと思います。
どの暗号技術を選べばいいか迷ったら、とりあえずこのリストの中から選択すれば間違いありません。しかし、暗号技術とセットで使われる鍵長がある程度長くなければいけません。
このリストの暗号技術が危殆化した場合には、直ちに削除とはならずに運用監視暗号リストに遷移します。
以下が電子政府推奨暗号リストに掲載されている暗号技術になります。
出典:電子政府における調達のために参照すべき暗号のリスト(CRYPTREC暗号リスト) ⧉
推奨候補暗号リスト
推奨候補暗号リストは安全性及び実装性能を確認され、今後、電子政府推奨暗号リストに掲載される可能性のある暗号技術のリストです。公募や事務局で提案されたものを検討委員会で審議し、安全性・実装性能が十分と判断された暗号技術がこのリストに掲載されます。
こちらのリストから暗号技術を選択することは問題ないですが、危殆化した場合や掲載後長期間(20年程)の利用実績が不十分と判断された場合、または自主取り下げ要望が受理された場合、運用監視暗号リストへ遷移することなく、リストから直接削除されます。その点に注意が必要です。
出典:電子政府における調達のために参照すべき暗号のリスト(CRYPTREC暗号リスト) ⧉
運用監視暗号リスト
実際に解読されるリスクが高まるなど、推奨すべき状態ではなくなったと確認されたが、互換性維持のために継続利用を容認する暗号技術のリストが運用監視暗号リストです。基本的には、このリストに遷移した場合、利用する暗号技術の変更を検討すべきです。また、このリストから削除される場合は、削除猶予期間が設けられ、期間終了後にリストから削除される運用になっています。
出典:電子政府における調達のために参照すべき暗号のリスト(CRYPTREC暗号リスト) ⧉
その他
3つのリストのどれにも載っていない暗号技術は安全性が損なわれているため利用は推奨されません。もし、リストに載っていない暗号技術を利用していた場合は、速やかに変更しましょう。
各リストの関係図を載せておきます。
出典:CRYPTREC暗号リスト改定報告 ⧉ p.7を加工して作成
暗号強度と寿命
暗号技術の強度はどのように評価されるのでしょうか?暗号技術の強度(暗号強度、セキュリティ強度)は解読計算量の多さと利用する鍵長で決まります。選択したアルゴリズムの解読計算量が多ければ多いほど、利用する鍵長が長ければ長いほどセキュリティ強度が高くなります。
ビットセキュリティ
分類が異なる暗号技術のアルゴリズムについて、同じ程度のセキュリティ性を持っているかを判断する目安として「ビットセキュリティ」という指標が存在します。これは対象のアルゴリズムに対して最も効果的な攻撃手法を用いた時に、どの程度の計算量があれば解読できるか(解読計算量)を示した値で、鍵長とは別に求められます。たとえば、解読計算量が2のx乗だった場合には「xビットセキュリティ」と表記します。
鍵長
鍵長は分かりやすくビットの長さがそのまま指標になります。64bitの鍵長でも1844京6744兆737億955万1616個のパターンになり、256bitにもなると天文学的な数になります。
強度が強い方が良いの?
セキュリティ強度が強いとその暗号の解読に時間を有します。例えば、AES-256という共通鍵暗号でよく使われるAESの256bit鍵長の場合、現在のスーパーコンピュータで総当たり攻撃しても数百兆年かかるといわれています。
ですが、一番強度の強いものを使えば良いというわけではありません。強度が強い暗号技術は、その処理にも時間がかかります。安全性と処理時間を天秤にかけて、適切なものを選択する必要があります。
暗号技術の組み合わせ
暗号技術はその用途によって様々あり、複数の暗号技術を組み合わせて運用します。その際、全体のセキュリティ強度は組み合わせの中で最もセキュリティ強度が弱い暗号技術のアルゴリズムと鍵長の組み合わせによって決定されます。どれか1つでも解読されてしまうと、そこから突破されてしまうからです。図のような場合は、最も低い署名のセキュリティ強度が全体の強度になります。
出典:暗号強度要件(アルゴリズム及び鍵長選択)に関する設定基準 ⧉ p.11 図2を加工して作成
暗号技術の寿命
しかし、強度の強い暗号技術を処理するCPUの性能が上がるということは、それを解読してしまうCPUもまた性能が上がっていることを忘れてはいけません。2年ごとにCPU性能が約2倍になるというムーアの法則に従うと、今のCPU性能が向上していき、やがては解読されるのも時間の問題です。そのため、暗号技術にも寿命というものが存在します。暗号技術の寿命は、その暗号技術を処理可能な期限が寿命となり、証明書の発行(新規作成)はその有効期間分引いた日時が期限になります。
以下にセキュリティ強度毎にいつまで利用可能かを示した表を載せておきます。差し迫って112ビットセキュリティのものが2031年以降に利用非推奨(複合化のみ許容される)となっています。電子政府推奨暗号リストに載っているものだとDSA(公開鍵の鍵長:2048bit、秘密鍵の鍵長:224bit)や後述するRSAの鍵長2048bitが該当します。早めにセキュリティ強度の高いものへ変更することを検討するといいでしょう。
出典:暗号強度要件(アルゴリズム及び鍵長選択)に関する設定基準 ⧉ p.16 表5
余談 マイナンバーカードは大丈夫?
ちなみに、マイナンバーカードに使われている暗号技術ってご存じですか?マイナンバーカードに格納されている電子証明書の公開鍵暗号方式にRSAの2048bitが使用されています。そのセキュリティ強度は112ビットセキュリティになります。これは執筆時点(2025年1月)で既に移行完遂期間に入っており、2031年からは新規作成ができなくなります。2026年10月頃にカードが新しく変わるようですが、それに伴って暗号方式もセキュリティ強度の高いものへ変更されます。しかし、2026年中に変わることが少々厄介だったりします。
現在のマイナンバーカードは電子証明書の有効期限が5年です。そのため、2026年1月から次期カード開始までの期間に発行・更新した場合、電子証明書の有効期限が、使用している暗号技術の移行完遂期間を超えてしまいます。暗号技術の寿命を示した表では、処理はまだ許容される期間ではありますが、可能であれば移行期間中に変えておきたいところです。
出典:デジタル庁 次期個人番号カード仕様に係る検討事項について ⧉ p.33 を加工して作成
量子コンピュータとその対策
暗号技術の寿命について触れたので、量子コンピュータについても軽く触れておきます。大規模な量子コンピュータが利用可能となった場合、現在の暗号技術は過去のものになる可能性があります。そこで、量子コンピュータが苦手とする問題(格子問題、多変数多項式問題など)を基にした耐量子計算機暗号(PQC)が必要です。
CRYPTREC ⧉は、現時点では量子コンピュータによる解読の可能性は低いとしつつも、技術の進展により解読される可能性を否定できないとしています。アメリカ国立標準技術研究所(NIST)は2016年から耐量子計算機暗号の標準化プロジェクトを開始し、2024年8月に以下の3つのアルゴリズムを標準化しました。
FIPS※ | 標準名 | アルゴリズム名 | 用途 |
---|---|---|---|
FIPS203 | Module-Lattice-Based Key-Encapsulation Mechanism Standard | ML-KEM | 鍵交換や暗号化 |
FIPS204 | Module-Lattice-Based Digital Signature Standard | ML-DSA | デジタル署名 |
FIPS205 | Stateless Hash-Based Digital Signature Standard | SLH-DSA | デジタル署名 |
因みに、本記事執筆中に耐量子計算機暗号を利用した通信に成功した ⧉というニュースが流れてきました。まだ実用化は先の話ですが、技術は日々進化していくものだと実感しますね。
実践編
112ビットセキュリティの暗号技術は2031年から非推奨になることを説明しましたが、証明書の有効期限から逆算すると2031年は意外と近い話なのです。より強いセキュリティ強度の暗号技術への変更が必要になります。
ここでは、Web通信に用いる暗号方式を電子政府推奨暗号リストの要件を満しつつ、セキュリティ強度の高いもの(128ビットセキュリティ以上)へ設定する方法について紹介します。
暗号スイート
実際に使う場合、どの組み合わせで運用するのかを設定するものとして暗号スイートを用います。暗号スイートは、Transport Layer Security(TLS)をはじめとしたセキュリティプロトコルで使用される暗号アルゴリズムの組み合わせを示したものになります。これにより、通信の機密性、完全性、認証を確保します。
設定方法を紹介する前に、暗号スイートの構成要素を簡単に説明しておきます。
鍵交換アルゴリズム
鍵交換アルゴリズムは、通信を行う両者がセッション鍵を安全に共有するために使用されます。電子政府推奨暗号リストに記載されているもので挙げると、DHE(DH鍵交換アルゴリズム)やECDHE(楕円曲線DH鍵交換アルゴリズム)があります。
鍵長の長さでそのセキュリティ強度が決まるので、3072bit(DHEの公開鍵)以上、256bit(DHEの秘密鍵やECDHEの鍵長)以上を目安に選定するといいでしょう。
署名アルゴリズム
署名アルゴリズムは、通信相手の認証を行うために使用されます。電子政府推奨暗号リストに記載されているもので挙げると、RSAやECDSAがあります。
こちらも鍵交換と同様に鍵長の長さでセキュリティ強度が決まるので、3072bit(RSAの鍵長)以上、256bit(ECDSAの鍵長)以上を目安に選定してください。
暗号化アルゴリズム
暗号化アルゴリズムは、データの機密性を確保するために使用されます。暗号化方式とブロック処理のセットで扱われることが多いです。電子政府推奨暗号リストに記載されているもので挙げると、暗号化はAESやChaCha20-Poly1305、ブロック処理はCCMやGCMがあります。
暗号化はAESの鍵長 128bit以上のものかKCipher-2、ChaCha20-Poly1305から、ブロック処理はCCMかGCMから選択すれば、128ビットセキュリティは確保できます。
ハッシュ関数
ハッシュ関数は、データの完全性を確認するために使用されます。電子政府推奨暗号リストに記載されているもので挙げると、SHA-256があります。
SHA-256が128ビットセキュリティですので、電子政府推奨暗号リストに記載されているものから選択すれば問題ないでしょう。
TLSバージョンによる違い
TLSのバージョン(1.2と1.3)で暗号スイートの構成が以下のように変わり、シンプルになりました。
TLS1.2: 鍵交換 + 署名 + 暗号化 + ハッシュ
TLS1.3: 暗号化 + ハッシュ
鍵交換と署名部分はなくなった訳ではなく、ハンドシェイク時にやり取りされるClient HelloとServer Helloで指定します。具体的には、鍵交換はsupported_groupsという拡張領域を、署名はsignature_algorithmsという拡張領域を使います。
TLS 1.2では危殆化した暗号アルゴリズムも残していたため、使用可能な暗号アルゴリズムが増え続け、その組み合わせである暗号スイートは100種類を超えていました。互換性はあるものの明示的に設定しない限りは、セキュリティ強度が低い暗号アルゴリズムを使うリスクがついて回りました。TLS 1.3では使用できる暗号アルゴリズムを絞り込み、使用できる暗号スイートは5種類まで整理されました。
以下に、TLSで使用される暗号スイートの例を示します。
-
ECDHE-RSA-AES128-GCM-SHA256
- 鍵交換: ECDHE
- 署名: RSA
- 暗号化: AES-128-GCM
- ハッシュ: SHA-256
-
TLS_AES_256_GCM_SHA384
- 暗号化: AES-256-GCM
- ハッシュ: SHA-384
暗号スイートは、セキュリティ要件やパフォーマンス要件に応じて選択されます。適切な暗号スイートを選択することで、セキュアな通信を実現することができます。
実際に設定してみよう
暗号スイートについての理解が深まったところで、nginxを使って暗号スイートを適用する方法を紹介します。また、今回紹介する手順では以下の環境で実施しています。
名称 | バージョン |
---|---|
nginx | v1.24.0 |
OpenSSL | v3.4.0 |
サーバ機 | Windows 11 24H2 |
クライアント機 | Windows 11 23H2 |
1.証明書を用意する
認証局に証明書の発行を依頼することになりますが、その際によりセキュリティ強度の高いものへ変更しましょう。
2.設定できる暗号スイートを確認する
nginxの設定を変更して通信を許可する暗号スイートを設定するのですが、OSやブラウザ等にも依存していて利用可能な暗号スイートが多少異なる可能性があるため、どの暗号スイートが設定できるのか確認する必要があります。
以下のコマンドでそのサーバで設定可能な暗号スイートを一覧で出力することが出来ます。
> openssl ciphers -v
出力される暗号スイートは以下の形式で出力されます。
[暗号スイート名] [プロトコルバージョン] Kx=[鍵交換方式] Au=[署名方式] Enc=[暗号化方式] Mac=[メッセージ認証の方式]
そして実行した結果は以下になります。
※数が多いので中略しています
>openssl ciphers -vTLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEADTLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEADTLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEADECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEADECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEADDHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256・・・DHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA256RSA-PSK-AES128-CBC-SHA SSLv3 Kx=RSAPSK Au=RSA Enc=AES(128) Mac=SHA1DHE-PSK-AES128-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA1AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1PSK-AES128-CBC-SHA256 TLSv1 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA256PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
3.nginx設定ファイルを開く
設定ファイルはnginx/nginx.conf
またはnginx/conf/nginx.conf
にあります。
4.nginx.confを編集する
以下に、こちらの設定 ⧉で記載されている高セキュリティ型の設定をnginxに適用した例を載せておきます。
手順1で出力させた暗号スイートのリストと見比べて、取捨選択をするといいでしょう。記載している暗号スイートは128ビットセキュリティ以上の暗号スイートになっていますので、迷ったら暗号スイートの設定をコピーして使っても構いません。ただし、サーバ証明書の有効期限や暗号スイートの互換性を考慮する必要があります。
ssl_certificate cert.pem; ssl_certificate_key cert.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_dhparam dhparam.pem; ssl_ecdh_curve X25519:X448:P-256:P-384:P-521; ssl_prefer_server_ciphers on; ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES128-CCM8:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-CCM:DHE-RSA-AES128-CCM8;
各要素について説明をします。
ssl_certificateとssl_certificate_key
ssl_certificateにサーバ証明書のファイルパスを、ssl_certificate_keyに秘密鍵のファイルのパスを指定してください。
ssl_protocols
使用するTLS/SSLのバージョンを指定してください。基本的にTLSv1.2とTLSv1.3を使用することになるでしょう。それ以前のバージョンは脆弱性が発見されていますので使用は控えてください。
ssl_dhparam
後述する暗号スイートの設定で、DHEを含むものを使用する場合にパラメタファイルのパスを指定してください。ファイルの指定がないとDHEを含む暗号スイートは設定できなくなるので注意してください。
DHパラメタファイルを作成するコマンドを載せておきます。鍵長を3072以上にするといいでしょう。
> openssl dhparam [鍵長] -out [出力ファイルパス]
ssl_ecdh_curve
後述する暗号スイートの設定で、ECDHEを含むものを使用する場合に、ECDHEで使用される鍵長のグループを指定してださい。記載例はいずれも128ビットセキュリティ以上の設定になっていますので、そのままコピーしても構いません。デフォルトでP-256が使用されるため、ssl_ecdh_curveは設定しなくても128ビットセキュリティで動作します。
ssl_prefer_server_ciphers
サーバに設定した暗号スイートを優先するかの設定をしてください。(on
:サーバ優先、off
:クライアント優先(デフォルト))
off
にした場合、サーバに設定した暗号スイートが使われなくなるため、必ずon
にするようにしてください。
ssl_conf_command Ciphersuites
TLSv1.3の暗号スイートを設定してください。ssl_ciphersも同様ですが:
(コロン)で暗号スイート同士は区切ってください。このディレクティブにはTLSv1.3の暗号スイートを、後述するssl_ciphersにはTLSv1.2の暗号スイートを設定する必要がありますので、注意してください。
ssl_ciphers
TLSv1.2の暗号スイートを設定してください。記載された順に優先されるため、ECDHEで始まる暗号スイート、DHEで始まる暗号スイートの順に記載するのが通例となっています。
5.nginxの再起動
最後にnginxを再起動すれば設定が切り替わります。
> nginx -s reload
設定されているか確認しよう
opensslコマンドを使った確認方法を紹介します。
openssl s_client -connect [対象のサーバアドレス]:[ポート番号] [プロトコルバージョン] -servername [対象のサーバアドレス] -cipher [暗号スイート名]
TLS1.3の場合は暗号スイートを指定するオプションが異なるので注意してください。
openssl s_client -connect [対象のサーバアドレス]:[ポート番号] -tls1_3 -servername [対象のサーバアドレス] -ciphersuites [暗号スイート名]
実行した結果は以下のようになります。
※サーバアドレスは伏字に変えています
>openssl s_client -connect x.x.x.x:443 -tls1_3 -servername x.x.x.x -ciphersuites TLS_AES_256_GCM_SHA384Connecting to x.x.x.xCONNECTED(000001B0)depth=0 CN=hogehogeverify error:num=18:self-signed certificateverify return:1depth=0 CN=hogehogeverify return:1・・・---New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384Protocol: TLSv1.3Server public key is 4096 bitThis TLS version forbids renegotiation.Compression: NONEExpansion: NONENo ALPN negotiatedEarly data was not sentVerify return code: 18 (self-signed certificate)---・・・
余談 何の暗号技術が使われているのか見てみよう(Web編)
Webの通信でどのような暗号技術が使われているかを確認する方法を簡単に紹介します。(Google Chromeでの方法になります)
- 確認したいURLに遷移してください。
- 「F12」または「Ctrl + Shift + I」でデベロッパーツールを開いてください。
- デベロッパーツールのセキュリティタブをクリックしてください。
- 接続に記載されている内容が、そのWeb通信で使われている暗号化技術とTLSのバージョンになります。
以下の画像はGoogleのホームページ(https://www.google.co.jp/
)でやってみた結果になります。どうやら耐量子計算機暗号のML-KEMを既に取り入れているようです。調べたところ2024年11月頃(Chromeバージョン131) ⧉にKyberからML-KEMに変わったそうです。
まとめ
暗号技術は私たちの生活の中で非常に重要な役割を果たしています。特に、電子政府推奨暗号リストは、安全で信頼性の高い暗号技術を選定するための重要な指針となります。この記事を通じて暗号技術の基本から最新の動向までを理解し、適切な暗号技術を選定するための知識を深めていただけたなら幸いです。
また暗号技術は日々進化しており、常に最新の情報をキャッチアップすることが重要です。特に量子コンピュータの登場により、今後の暗号技術の動向にも注目が必要です。暗号技術の選定や運用においてはセキュリティ強度とパフォーマンスのバランスを考慮し、適切な暗号スイートを選択することが求められます。
最後までお読みいただき、ありがとうございました。
参考文献: