はじめに
インターネット上でやり取りする情報を安全に守るため、SSL/TLSは日常的に使われています。本記事は、そのSSL/TLSに関係する「384」という数字に注目し、実務で役立つ知識をわかりやすくまとめています。
ここで扱う主な内容は次の通りです。
- SHA-384というハッシュ関数と、ECDSA P-384という公開鍵暗号の特徴
- SSL/TLSプロトコルの中で「384」がどのように使われるか
- 実務でのメリット・デメリットと導入時の注意点
専門用語はできるだけ抑え、具体的な例を用いて説明します。技術者だけでなく運用担当やセキュリティに関心のある方にも読みやすい構成にしています。以降の章で、まずSSL/TLSの基本から順に丁寧に解説していきます。
SSL/TLSとは何か
概要
SSLはインターネット上の通信を暗号化して、第三者による盗聴や改ざんを防ぐ仕組みです。現在はより安全なTLSが実際の通信で使われます。例えば、銀行やメール、ショッピングサイトで個人情報をやり取りするときに役立ちます。
なぜ必要か
インターネット上のデータは途中で見られたり書き換えられたりします。SSL/TLSを使うと、通信内容を読めないようにし、相手が本当に正しいか確認できます。こうして情報の安全性と信頼性を高めます。
主な仕組み（4要素）
- 鍵交換：安全に共通鍵を決める仕組みです。例えると、安全な箱の中に入れる鍵をあらかじめ取り交わす作業です。
- 認証：相手が正当な相手か証明書で確かめます。証明書は身分証のようなものです。
- データ暗号化：通信内容を暗号にして、盗み見されても読めないようにします。
- ハッシュ（改ざん検出）：データが途中で変わっていないか短いチェック文字列で確かめます。
ハンドシェイク（簡単な流れ）
- ブラウザが接続の意思を伝えます（Hello）。
- サーバーが応答し、証明書を提示します。
- ブラウザが証明書を確認し、鍵交換の準備をします。
- 以後は共通鍵で安全にデータをやり取りします。
日常での確認方法
ブラウザのアドレス欄に「https://」や鍵マークが出ていれば、SSL/TLSで保護されています。証明書の詳細を見れば、発行者や有効期限も確認できます。
「384」が示すもの：SHA-384とECDSA P-384の概要
SHA-384とは
SHA-384はSHA-2ファミリーに属するハッシュ関数で、入力データから384ビット（48バイト）の固定長ハッシュ値を生成します。ハッシュ値はファイルやメッセージの「要約」で、改ざんを検出したりデジタル署名の前処理として使います。例えば大きなファイルを送る際にハッシュ値だけを比較すれば内容一致を簡単に確認できます。出力が長いほど衝突（異なる入力が同じハッシュを作る確率）が小さくなり、安全性が高まります。
ECDSA P-384とは
ECDSA P-384は楕円曲線暗号（ECC）の一種で、曲線のサイズが384ビットで設計されています。公開鍵暗号として署名や鍵交換に使います。P-384は同程度の安全性を保ちながらRSAより短い鍵長で済むため、通信データや計算量が減りやすいです。実際の署名は曲線の座標に基づく二つの整数（おおむね384ビットずつ）で表されます。
両者の組み合わせと注意点
実務ではメッセージをまずSHA-384でハッシュし、そのハッシュ値をECDSA P-384で署名することが多いです。こうすることでデータ量を減らしつつ高い安全性を確保できます。ただし安全に運用するには良好な乱数源と定数時間処理などの実装上の配慮が必要です。
SSL/TLSにおける384ビットの役割
概要
SSL/TLSの暗号スイートで「384」が使われる場面は主に二つです。SHA-384はハッシュ関数として、ECDSA P-384は公開鍵の署名・検証で使われます。これらが連携して通信の機密性・完全性・認証を支えます。
SHA-384の役割（完全性）
SHA-384はデータ改ざんを検出するために使います。ハンドシェイクや証明書の検証、鍵導出の過程でハッシュ値を作り、送受信データの整合性を確認します。例として暗号スイート名の末尾にSHA384があると、ハッシュにSHA-384が用いられていると理解できます。
ECDSA P-384の役割（認証）
サーバ証明書や署名にP-384曲線の鍵を使うと、署名の強度が高まります。クライアントは証明書の署名を検証して相手の正当性を確認します。P-384はより高い安全性を求める場面で選ばれます。
暗号スイートの流れ（例）
例: ECDHE-ECDSA-AES256-GCM-SHA384
1. クライアントが暗号スイートを提案する
2. サーバがECDSA P-384で署名された証明書を提示する
3. 双方がECDHEで共通鍵を作る
4. AES-GCMで機密性を確保し、ハッシュやPRFにSHA-384を使って鍵や整合性情報を導出する
実務上の注意点
P-384はP-256より計算負荷が高い点に注意してください。すべてのクライアントが対応するとは限りません。互換性と性能を見て、必要な場面で採用するとよいです。
384ビット利用のメリット・デメリット
メリット
- 高い暗号強度：SHA-384やECCのP-384は、SHA-256やP-256より大きな安全余裕を持ちます。たとえばP-384は非常に大きなRSA鍵（例：RSA-7680）に相当する強度を提供します。
- 鍵長と性能のバランス：RSAと比べて鍵や証明書サイズが小さく、署名も短いため通信負荷と記憶領域が節約できます。サーバ側では署名・検証が高速で、TLSハンドシェイクが短くなることが多いです。
- サポートの充実：主要なクラウドや証明書発行機関はP-384やSHA-384をサポートしており、実運用で導入しやすいです。
デメリット
- 互換性の問題：古い組込み機器や旧ブラウザではP-384やSHA-384に未対応の場合があります。レガシー環境と相互運用する際は注意が必要です。
- 処理負荷：P-384はP-256より計算コストが高く、特に低消費電力デバイスでは負荷増加が目立ちます。
- デフォルトの採用率：多くのツールやサービスでP-256/SHA-256が既定設定のまま使われることが多く、切り替えには設定や検証が必要です。
実務上の注意点
- 段階的導入：まずサーバでP-384/SHA-384を優先しつつ、P-256などをフォールバックに残して互換性を確保します。
- 検証を必ず行う：主要クライアントやIoT機器で接続テストを実施してください。負荷試験でCPUやレイテンシの影響も確認します。
第6章: まとめ・実務での活用ポイント
SSL/TLSにおけるSHA-384やECDSA P-384は、高い安全性を比較的効率よく提供します。特にTLS 1.2/1.3を採用する環境で有効で、セキュリティポリシーや規制で強い耐性が求められる場合に有力な選択肢です。
実務での優先事項
- サポート確認：サーバー（OpenSSL、TLSライブラリ）やクライアントの対応状況をまず確認してください。古い環境では非対応の可能性があります。
- パフォーマンス検証：ECDSA P-384はRSAに比べ鍵サイズが小さく計算も速い場合がありますが、実際の負荷を負荷試験で測定してください。
- 暗号スイート選定：互換性と安全性のバランスを取った順序で推奨します。サーバー設定で優先順位を明確にしてください。
- 秘密鍵管理と証明書：P-384用の鍵生成と安全な保管、証明書の有効期限管理を徹底してください。
移行と運用のポイント
段階的に導入し、テスト環境で接続互換性とパフォーマンスを確認してから本番へ反映してください。ログや監査で暗号の利用状況を継続的に監視すると安全性が維持されます。
実務では「サポート状況の確認」「性能検証」「運用管理」の3点を中心に判断すると運用が安定します。
