Posted inPython

Pythonのcryptographyライブラリ入門：AES・RSA暗号化と安全な鍵管理の実践

Python tutorial - IT technology blog
Python tutorial - IT technology blog

背景：なぜアプリケーション層での暗号化が必要なのか？

約4年前、初めて決済APIを構築した際、今でも忘れられない苦いミスを犯したことがあります。ユーザーの身分証明書番号やアクセストークンを平文（plaintext）のまま直接データベースに保存してしまっていたのです。Pull Requestのレビュー段階でテックリードに即座に差し戻され、データ永続化層の全面的な書き直しを命じられました。そこで得た教訓は明白でした。ディスク暗号化（TDE）やSSL/TLSだけに頼るのでは不十分だということです。もしSQLインジェクション脆弱性を突かれたり、2GBのSQLバックアップファイルがネットワーク上に流出したりすれば、ユーザーデータは一瞬にして危険に晒されてしまいます。

Pythonで暗号化ソリューションを探すと、古いチュートリアルでは今でもpycrypto（2013年にメンテナンス終了）やpycryptodomeが紹介されていることがあります。しかし、現在のデファクトスタンダード（黄金基準）は、PyCA（Python Cryptographic Authority）が開発するcryptographyです。

このライブラリは、安全性の高い高レベルな抽象化層（Fernetなどの高レベルレシピ）と、低レベルの暗号プリミティブを集約したhazmat（Hazardous Materialsの略）パッケージの2層に明確に分離されています。この命名は一種の警告でもあります。hazmatを直接操作するには暗号アルゴリズムへの深い理解が必要であり、誤った使い方をすると脆弱性を自ら生み出してしまうリスクがあるからです。

日々の開発で直面する代表的な暗号化タスクは、主に以下の2つです。

  • 共通鍵暗号（AES）：暗号化と復号で同一のシークレットキー（Secret Key）を使用します。CPUのAES-NI命令セットを活用することで数百MB/sの処理速度を実現でき、APIのペイロード、添付ファイル、DB内の機密フィールドの保護に最適です。
  • 公開鍵暗号（RSA）：暗号化用のPublic Key（公開鍵）と復号用のPrivate Key（秘密鍵）のペアを使用します。RSAは計算負荷が非常に高く、AESに比べて1,000〜3,000倍低速です。そのため、セッション鍵の交換（ハンドシェイク）、電子署名、または身元認証にのみ限定して利用されます。

以前、10万件のユーザーレコードの暗号化ベンチマークを実施した際、無理にRSAを適用した結果、CPU使用率が100%に張り付いたまま完了まで約40分もかかりました。しかし、AES-GCMを組み合わせたハイブリッド暗号（Hybrid Encryption）に切り替えたところ、スクリプト全体がわずか3秒未満で完了したのです。

環境構築

cryptographyのコア部分は、パフォーマンスの最適化とメモリリーク防止のためにCおよびRustで記述されています。本パッケージは専用の仮想環境（virtual environment）にインストールすることを推奨します。

# 仮想環境の作成と有効化
python3 -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate

# pipのアップグレードとcryptography wheelのインストール
pip install --upgrade pip
pip install cryptography

環境が正しくドライバとOpenSSLバックエンドを認識しているか確認するため、バージョンを素早くチェックします：

python -c "import cryptography; print(f'Version: {cryptography.__version__}')"

暗号化の実践と実装

1. FernetおよびAES-GCMによる共通鍵暗号化

トークン文字列やCookie、またはPython内部で完結するデータを手軽に暗号化したい場合、Fernetが最も手軽で安全な選択肢です。FernetはCBCモードのAES-128と完全性検証のためのHMAC-SHA256を組み合わせ、さらにリプレイ攻撃（replay attack）を防ぐための64ビットタイムスタンプを備えています。

from cryptography.fernet import Fernet

# 1. ランダムなキーの生成（32バイトのURLセーフなBase64）
secret_key = Fernet.generate_key()
print(f"シークレットキー（厳重に管理）: {secret_key.decode()}")

cipher_suite = Fernet(secret_key)

# 2. データの暗号化（bytes型への変換が必須）
raw_message = "身分証明書番号: 079090001234".encode('utf-8')
cipher_text = cipher_suite.encrypt(raw_message)
print(f"Ciphertext: {cipher_text.decode()}")

# 3. データの復号
plain_text = cipher_suite.decrypt(cipher_text)
print(f"復号結果: {plain_text.decode('utf-8')}")

ただし、Fernetは生成されるペイロードが肥大化しやすく、GoやJavaで構築された他言語のマイクロサービスと連携しづらいという難点があります。AEAD（Authenticated Encryption with Associated Data：関連データ付き認証暗号）標準が必要な場面では、AES-GCM（Galois/Counter Mode）が業界標準のソリューションとなります。ここで重要なのは、nonce（12バイト）は同一の鍵に対して暗号化ごとに必ず一意でなければならないという点です。AES-GCMでnonceを再利用すると、攻撃者に認証鍵と平文の両方を復元される危険性があります。

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

# 高セキュリティな256ビット鍵の生成
aes_key = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(aes_key)

# GCMの標準nonce長は常に12バイト（96ビット）
nonce = os.urandom(12)
data_to_encrypt = "銀行口座番号: 19034567890123".encode('utf-8')
associated_data = b"tenant_id_8841"  # 暗号化はされないが完全性が保護されるコンテキストデータ

# 暗号化の実行（返却されるciphertextには16バイトの認証タグが自動で付与される）
ciphertext = aesgcm.encrypt(nonce, data_to_encrypt, associated_data)

# データベース保存用にnonceとciphertextを連結してパッケージ化
payload = nonce + ciphertext

# 受信側：nonceの分離と復号
extracted_nonce = payload[:12]
extracted_ciphertext = payload[12:]
decrypted_data = aesgcm.decrypt(extracted_nonce, extracted_ciphertext, associated_data)
print("復号された平文:", decrypted_data.decode('utf-8'))

このバイト列をPostgreSQLに（VARCHARとして）保存したり、JSON APIに埋め込んだりする場合、一般的にはBase64形式にエンコードします。パディングエラーや破損したペイロードのデバッグ時には、ToolCraftのBase64 Encoder/Decoderによく文字列を貼り付けて確認しています。このツールはブラウザ上のJavaScriptのみで100%処理され、サーバーへのリクエスト送信が発生しないため、機密性の高いテスト文字列が漏洩する心配がありません。

2. RSA-OAEPによる公開鍵暗号化

RSAは鍵配送問題を根本から解決します。Public Key（公開鍵）は相手に自由に渡すことができますが、データを復号できるのはサーバー上に保持されたPrivate Key（秘密鍵）のみです。NISTのガイドラインによると、現在推奨されるRSAの鍵長は最低でも2048ビット（推奨は3072ビットまたは4096ビット）とされています。

from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes, serialization

# 1. 2048ビットRSAキーペアの生成
private_key = rsa.generate_private_key(
    public_exponent=65537,
    key_size=2048
)
public_key = private_key.public_key()

# 2. OAEPパディングを用いた公開鍵での暗号化（Bleichenbacher攻撃の脆弱性があるためPKCS1v15の使用は厳禁）
session_key = b"aes-secret-key-32-bytes-length!!"
encrypted_session_key = public_key.encrypt(
    session_key,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)

# 3. 受信側：秘密鍵による復号
decrypted_key = private_key.decrypt(
    encrypted_session_key,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)
print("受信したセッションキー:", decrypted_key.decode('utf-8'))

3. Private Keyの安全な管理と保存

GitリポジトリへのPrivate Keyのハードコードは、重大なデータ漏洩事故を引き起こす最大の要因の一つです。安全基準に従い、鍵はPEM形式にシリアライズした上で、十分な強度を持つパスフレーズ（passphrase）で暗号化して保存する必要があります。

passphrase = b"k9#mP$91!vLa@xQ72zR4"  # シークレットマネージャーまたは環境変数から取得

# AES-256で暗号化されたPKCS8形式で秘密鍵を出力
pem_private = private_key.private_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PrivateFormat.PKCS8,
    encryption_algorithm=serialization.BestAvailableEncryption(passphrase)
)

with open("private_key.pem", "wb") as f:
    f.write(pem_private)

# 外部共有用の標準X.509 SubjectPublicKeyInfo形式で公開鍵を出力
pem_public = public_key.public_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PublicFormat.SubjectPublicKeyInfo
)

with open("public_key.pem", "wb") as f:
    f.write(pem_public)

PEMファイルを保護するパスフレーズに単純な文字列を使用してはいけません。最低でも128ビットのエントロピーを持つランダム文字列が必要です。筆者はToolCraftのPassword Generatorを活用して、大文字・小文字・数字・記号を組み合わせた32文字のランダム文字列を生成しています。クライアントサイドで動作するため、生成されたパスワードが端末外に送信されることはありません。

サービス起動時、アプリケーションはPEMファイルを読み込んでメモリ（RAM）上に鍵を展開します：

with open("private_key.pem", "rb") as f:
    loaded_private_key = serialization.load_pem_private_key(
        f.read(),
        password=passphrase
    )

検証・エラーハンドリング・モニタリング

改ざん検知（Tampering Detection）とエラーハンドリング

AEADモードの大きな強みは、その耐改ざん性にあります。ペイロードが攻撃者によってわずか1ビットでも改ざんされた場合、復号処理は即座にInvalidTag例外をスローします。復号ブロックは必ず厳密なtry-except構文で保護してください：

from cryptography.exceptions import InvalidTag

# 送信途中でパケットが改ざんされたシナリオをシミュレート
corrupted_payload = bytearray(payload)
corrupted_payload[-1] ^= 0x01  # 認証タグの最後の1ビットを反転
try:
    bad_nonce = bytes(corrupted_payload[:12])
    bad_cipher = bytes(corrupted_payload[12:])
    aesgcm.decrypt(bad_nonce, bad_cipher, associated_data)
except InvalidTag:
    # 即座にCRITICALレベルのアラートログを出力
    print("[ALERT] データが改ざんされているか、associated dataが一致しません！")

SHA-256によるデータ完全性チェック

バックアップファイルやアップロードされたデータが転送途中で破損していないことを保証するために、暗号学的ハッシュ関数によるチェックサム検証は欠かせない工程です：

from cryptography.hazmat.primitives import hashes

hash_engine = hashes.Hash(hashes.SHA256())
hash_engine.update("検証対象のペイロードデータ".encode('utf-8'))
file_checksum = hash_engine.finalize().hex()
print(f"SHA-256 Checksum: {file_checksum}")

サードパーティのWebhook（StripeやVNPayなど）と連携する際、受信した署名やハッシュ値の照合が頻繁に発生します。筆者はターミナルでいちいちワンライナーのPythonスクリプトを打つ代わりに、ToolCraftのHash Generatorにペイロードを貼り付けて、視覚的にSHA-256ハッシュ値を照合しています。

本番運用のためのチェックリスト

暗号化モジュールを本番環境へデプロイする前に、システムが以下の3つの技術要件を満たしているか確認してください：

  1. エンベロープ暗号化（Envelope Encryption）モデル：大容量ファイルや巨大なペイロードの暗号化にRSAを直接使用してはいけません。必ず使い捨てのAES Data Keyを生成して実データを暗号化し、そのData Key自体をRSA Public Keyで暗号化する方式を採用してください。
  2. Grafanaによる異常検知アラート：InvalidTag例外の発生頻度をカウントするメトリクスを作成します。この数値が5件/分を超えた場合、リプレイ攻撃や認証タグに対するブルートフォース攻撃を受けている可能性が高いと考えられます。
  3. 鍵ローテーション（Key Rotation）戦略：保存データのプレフィックスを{key_version}:{nonce}:{ciphertext}（例：v1:...）のように設計します。PCI-DSS要件に基づき90日ごとに鍵をローテーションする際も、バックグラウンドワーカーがバージョン情報を参照して古いデータを復号し、ダウンタイムなしで新しい鍵で再暗号化できます。
Share:
Tags: