Cryptographic Analysis & Assessment

暗号解析・評価

目的

SSL/TLS 設定監査、暗号スイートの分析と推奨、ハッシュアルゴリズムの特定、暗号化実装コードのレビュー、鍵管理の評価、暗号の脆弱性の検出など、暗号セキュリティ評価を Claude が支援できるようにします。Claude は、提供された設定とコードを直接分析します。

---

有効化のトリガー

ユーザーが次のことを尋ねた場合に、このスキルが有効になります。

• サーバーまたはサービスの SSL/TLS 設定の監査
• 暗号スイートのセキュリティ強度の評価
• ハッシュ値またはコードからのハッシュアルゴリズムの特定
• 暗号実装の不備がないかコードをレビュー
• 鍵長、鍵管理、ローテーションポリシーの評価
• ハードコードされた鍵、弱い IV、ECB モードの使用の検出
• TLS 設定の推奨事項の作成（Mozilla プロファイル）
• 証明書の分析（有効期限、チェーン、透明性）
• 耐量子暗号に関するガイダンス
• パスワードハッシュの実装レビュー（bcrypt、Argon2、PBKDF2）

---

前提条件

pip install cryptography requests pyOpenSSL

推奨ツール：

• sslyze — Python TLS スキャナー
• testssl.sh — 包括的な TLS テスト
• openssl — コマンドライン TLS 操作
• Wireshark — TLS トラフィック分析
• certbot — 証明書管理

---

主な機能

1. SSL/TLS 設定監査

サーバーの TLS 監査や TLS 設定の貼り付けをユーザーが求めた場合：

コマンドラインによる監査方法：

# Quick TLS check using openssl
openssl s_client -connect example.com:443 -tls1_2 2>/dev/null | grep -E "Protocol|Cipher"
openssl s_client -connect example.com:443 -tls1 2>/dev/null | grep -E "handshake|error"

# Check certificate details
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Comprehensive scan with sslyze
sslyze --regular example.com --json_out result.json

# Or testssl.sh (most comprehensive)
./testssl.sh --severity HIGH --quiet example.com

# Use the skill's script
python scripts/tls_auditor.py --host example.com --port 443 --output report.json
python scripts/tls_auditor.py --host mail.example.com --port 993 --grade

TLS バージョンのサポート評価：

プロトコル	状態	対応
SSLv2	重大な脆弱性あり	直ちにブロック
SSLv3	脆弱（POODLE）	直ちにブロック
TLS 1.0	非推奨（PCI-DSS 違反）	無効化 — BEAST、POODLE
TLS 1.1	非推奨	無効化
TLS 1.2	許容可能（強力な暗号を使用する場合）	制限付きで維持
TLS 1.3	現行標準	有効にして優先

TLS 脆弱性チェックリスト：

[ ] Heartbleed (CVE-2014-0160): openssl s_client + heartbleed test
[ ] POODLE: SSLv3 enabled?
[ ] BEAST: TLS 1.0 + CBC cipher?
[ ] ROBOT: RSA key exchange supported?
[ ] DROWN: SSLv2 on any port of same server?
[ ] Logjam/FREAK: DHE < 2048-bit or EXPORT ciphers?
[ ] CRIME/BREACH: TLS compression enabled?
[ ] Sweet32: 3DES (64-bit block cipher) supported?
[ ] Weak certificate: RSA < 2048-bit, SHA-1 signed?
[ ] Certificate validity: Not expired, chain complete, not self-signed for prod?
[ ] HSTS: Strict-Transport-Security header present?
[ ] CT: Certificate in public transparency logs?

2. 暗号スイートの強度評価

暗号スイートのセキュリティについてユーザーが尋ねた場合：

TLS 1.3 暗号スイート（すべて安全 — これらを使用）：

暗号スイート	鍵交換	認証	暗号化	MAC	評価
TLS_AES_256_GCM_SHA384	ECDHE	RSA/ECDSA	AES-256-GCM	SHA-384	A+
TLS_CHACHA20_POLY1305_SHA256	ECDHE	RSA/ECDSA	ChaCha20	Poly1305	A+
TLS_AES_128_GCM_SHA256	ECDHE	RSA/ECDSA	AES-128-GCM	SHA-256	A

TLS 1.2 暗号スイートの評価：

暗号スイート	評価	備考
ECDHE-ECDSA-AES256-GCM-SHA384	A+	最適 — AEAD、PFS
ECDHE-RSA-AES256-GCM-SHA384	A+	最適 — AEAD、PFS
ECDHE-RSA-AES128-GCM-SHA256	A	良好 — AEAD、PFS
DHE-RSA-AES256-GCM-SHA384	A	良好 — DHE が 2048 ビット以上の場合
AES256-GCM-SHA384	B	前方秘匿性なし
ECDHE-RSA-AES256-SHA384	B	CBC モード（タイミング攻撃）
RC4-SHA	F	RC4 は脆弱 — 使用禁止
DES-CBC3-SHA	F	3DES は脆弱（Sweet32）
NULL-SHA	F	暗号化なし
EXPORT-RC4-MD5	F	FREAK に対して脆弱

推奨 nginx TLS 設定（Mozilla Modern プロファイル）：

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;  # TLS 1.3 ignores this; client order for TLS 1.2

# For TLS 1.2 compatibility
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

# DH parameters for DHE cipher suites
ssl_dhparam /etc/nginx/dhparam.pem;  # Generate: openssl dhparam -out dhparam.pem 4096

# Session management
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;  # Disabling improves forward secrecy

# HSTS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;

DH パラメーターを生成：

# 4096-bit DH parameters (do this once, takes a few minutes)
openssl dhparam -out /etc/nginx/dhparam.pem 4096

3. ハッシュアルゴリズムの識別と評価

ユーザーがハッシュ値を提示した場合、またはハッシュアルゴリズムの識別を求めた場合：

形式によるハッシュの識別：

ハッシュの形式／長さ	アルゴリズム	セキュリティ状況
32 個の 16 進文字	MD5	破られています — 衝突攻撃が存在します
40 個の 16 進文字	SHA-1	非推奨 — SHAttered 衝突
56 個の 16 進文字	SHA-224	許容可能（用途は限定的）
64 個の 16 進文字	SHA-256	現行標準
96 個の 16 進文字	SHA-384	強固
128 個の 16 進文字	SHA-512	強固
$apr1$...	MD5-APR（Apache）	脆弱 — 反復回数は 1000 回のみ
$1$...	MD5-crypt	破られています
$5$...	SHA-256-crypt	許容可能
$6$...	SHA-512-crypt	良好
$2b$12$...	bcrypt（コスト 12）	パスワード用として良好
$argon2id$...	Argon2id	パスワード用として最適
sha256:...	Django SHA-256	良好
pbkdf2_sha256$...	PBKDF2-SHA256	反復回数が 260,000 回以上なら良好

パスワードハッシュのセキュリティ評価：

bcrypt:
  $2b$10$... → cost factor 10 → ~100ms/hash → ACCEPTABLE
  $2b$12$... → cost factor 12 → ~400ms/hash → GOOD
  $2b$14$... → cost factor 14 → ~1.6s/hash  → STRONG

Argon2id (OWASP recommended):
  Minimum: m=19456 (19MB), t=2 iterations, p=1 parallelism
  Strong:  m=65536 (64MB), t=3 iterations, p=4 parallelism

PBKDF2:
  SHA-1: 1,300,000 iterations minimum (NIST 2023)
  SHA-256: 600,000 iterations minimum (NIST 2023)
  SHA-512: 210,000 iterations minimum (NIST 2023)

Avoid:
  Plain MD5/SHA-1 → instantly cracked
  bcrypt cost < 10 → too fast for modern hardware
  No salt → rainbow table attack
  SHA-256 without KDF → GPU-crackable

4. 暗号化実装のコードレビュー

ユーザーが暗号化に関する欠陥のコードレビューを求めた場合：

Claude はコードを直接読み、以下のパターンを指摘します。

Python 暗号処理におけるアンチパターン：

# INSECURE: Hardcoded encryption key
key = b"mysecretkey12345"  # ← NEVER hardcode keys
cipher = AES.new(key, AES.MODE_ECB)  # ← ECB mode is insecure

# INSECURE: ECB mode (produces identical ciphertext for identical blocks)
from Crypto.Cipher import AES
cipher = AES.new(key, AES.MODE_ECB)  # ← Pattern detection attacks possible

# INSECURE: Static/reused IV
iv = b"\x00" * 16  # ← Static IV allows pattern detection
cipher = AES.new(key, AES.MODE_CBC, iv)  # ← Reusing IV with same key = CRITICAL

# INSECURE: Weak hash for passwords
import hashlib
password_hash = hashlib.md5(password.encode()).hexdigest()  # ← GPU-crackable

# INSECURE: Trusting certificate errors
import ssl
ssl._create_default_https_context = ssl._create_unverified_context  # ← MitM possible
requests.get(url, verify=False)  # ← Never do this in production

Python 暗号処理における安全なパターン：

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
from cryptography.hazmat.primitives import hashes
import os, secrets

# SECURE: Derive key from password using PBKDF2
def derive_key(password: bytes, salt: bytes = None) -> tuple[bytes, bytes]:
    if salt is None:
        salt = secrets.token_bytes(32)  # 256-bit random salt
    kdf = PBKDF2HMAC(
        algorithm=hashes.SHA256(),
        length=32,  # 256-bit key
        salt=salt,
        iterations=600_000  # NIST 2023 minimum for PBKDF2-SHA256
    )
    key = kdf.derive(password)
    return key, salt

# SECURE: AES-GCM (authenticated encryption)
def encrypt(data: bytes, key: bytes) -> bytes:
    aesgcm = AESGCM(key)
    nonce = secrets.token_bytes(12)  # 96-bit random nonce (NEVER reuse!)
    ciphertext = aesgcm.encrypt(nonce, data, associated_data=None)
    return nonce + ciphertext  # Prepend nonce for decryption

def decrypt(ciphertext: bytes, key: bytes) -> bytes:
    aesgcm = AESGCM(key)
    nonce = ciphertext[:12]
    return aesgcm.decrypt(nonce, ciphertext[12:], associated_data=None)

# SECURE: Argon2id for password hashing
from argon2 import PasswordHasher
ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=4)
hashed = ph.hash(password)  # Automatic random salt
ph.verify(hashed, password)  # Verify with timing-safe comparison

コードレビューのチェックリスト：

Encryption:
[ ] No hardcoded keys (check for key = b"...", SECRET_KEY = "...", etc.)
[ ] No ECB mode (MODE_ECB, "AES/ECB/PKCS5Padding")
[ ] IV/Nonce is random and unique per encryption operation
[ ] Authenticated encryption used (AES-GCM, ChaCha20-Poly1305)
[ ] Key properly derived from password (PBKDF2, bcrypt, Argon2)
[ ] No custom/homebrew crypto algorithms

Certificate Handling:
[ ] Certificate validation is NOT disabled (verify=True)
[ ] Certificate pinning for mobile/critical apps
[ ] No ssl._create_unverified_context

Randomness:
[ ] Cryptographic operations use secrets module or os.urandom()
[ ] Not using random.random() or random.randint() for security
[ ] Tokens and OTPs have sufficient entropy (≥128 bits)

5. 鍵管理の評価

ユーザーが鍵管理について尋ねた場合：

鍵の長さに関する推奨事項（2025 年）：

アルゴリズム	最小値	推奨値	備考
RSA	2048-bit	3072-bit	NIST は 2030 年以降、3072-bit 以上を推奨しています
ECC（ECDSA）	P-256	P-384	P-256 は 2030 年まで問題ありません
AES	128-bit	256-bit	128-bit で十分です。重要度の高い用途には 256-bit を使用してください
ECDH（鍵交換）	P-256	P-384
DH（従来型）	2048-bit	3072-bit	使用を避け、ECDH を優先してください
SHA（ハッシュ処理）	SHA-256	SHA-256/384/512	SHA-1 は非推奨です

耐量子暗号への移行：

NIST は 2024 年に PQC 標準を最終決定しました。

• ML-KEM（CRYSTALS-Kyber） — 鍵カプセル化メカニズム（鍵交換において RSA/ECDH を置き換えます）
• ML-DSA（CRYSTALS-Dilithium） — デジタル署名（RSA/ECDSA を置き換えます）
• SLH-DSA（SPHINCS+） — ステートレスなハッシュベース署名（保守的な代替手段）

2030 年以降もデータを保護することが想定されるシステムでは、PQC への移行計画を始めてください。

鍵のローテーションスケジュール：

鍵の種類	推奨されるローテーション
TLS 証明書	毎年（または 90 日間有効な Let's Encrypt を使用）
署名鍵（JWT/API）	90 日
暗号化鍵（保存データ）	毎年
API キー／サービストークン	90 日またはサービスごと
従業員の SSH キー	毎年、および役割変更時
パスワードハッシュ	パスワード変更時

---

スクリプトリファレンス

tls_auditor.py

python scripts/tls_auditor.py --host example.com --port 443 --output report.json
python scripts/tls_auditor.py --host mail.example.com --port 993 --grade

---

スキルの連携

条件	関連スキル
Web アプリケーションの TLS 監査	← スキル 09（Web セキュリティ）
クラウドサービスの暗号化評価	← スキル 10（クラウドセキュリティ）
脆弱な暗号の検出結果 → 強化に関する推奨事項	→ スキル 15（ブルーチーム防御）
暗号処理の欠陥 → 脆弱性レポート	→ スキル 02（脆弱性スキャナー）

---

参考資料

• Mozilla SSL 設定ジェネレーター
• NIST SP 800-52 Rev. 2 — TLS ガイドライン
• SSL Labs の評価基準
• NIST 耐量子暗号標準
• OWASP 暗号処理の不備
• OWASP 暗号化ストレージのチートシート
• NIST パスワード保存ガイドライン

---

v3.0 の機能強化（2026 年の更新）

耐量子移行が運用段階に入りました：

• PQC 標準の確定 — FIPS 203（ML-KEM、鍵カプセル化）、FIPS 204（ML-DSA、署名）、FIPS 205（SLH-DSA、ハッシュベースの署名）が公開されています。新規設計ではこれらを推奨してください。FIPS 206（FN-DSA/Falcon）は今後公開予定です。
• ハイブリッド鍵交換 — TLS では、移行期間中に古典的攻撃と量子攻撃の両方に対して機密性を維持できるよう、ハイブリッドグループ（例：X25519+ML-KEM-768 / X25519MLKEM768）を推奨してください。
• 今取得して後で解読する攻撃 — 複数年にわたる機密性が求められる長期保存用の秘密情報やデータでは、PQC を優先してください。これは将来のリスクではなく、現在のリスクです。
• 暗号アジリティ — ハードコードされたアルゴリズムや鍵サイズを指摘し、プリミティブを交換できるよう抽象化を推奨してください。暗号技術のインベントリ（CBOM）を作成することが、移行の第一歩です。
• 厳格な非推奨化 — TLS 1.3 を優先し、TLS 1.0-1.1 は禁止します。SHA-1 および 2048 未満の RSA/DH は不合格として指摘します。RSA-2048 は現時点では許容されますが、PQC 移行の期限に向けたカウントダウンが始まっています。

精度に関するルール： 各検出結果には、プリミティブ、鍵サイズ／曲線、プロトコルのバージョン、および具体的なアップグレード（現時点での古典的方式と PQC の目標）を記載します。