【C#】AESとRSAで学ぶ暗号化・復号化の基本と安全なキー管理

C#で機密データを守るには、対称鍵方式のAesと非対称鍵方式のRSAを使うケースが主流です。

Aesは同じ鍵とIVで高速に暗号化と復号が行え、RSAは公開鍵で暗号化し秘密鍵で復号できるため鍵共有を安全に行えます。

シーンに合わせてアルゴリズムを選択し、鍵とパラメータを適切に管理することがセキュリティ維持の要になります。

暗号技術の基礎知識

暗号技術は情報の機密性や安全性を守るために欠かせない技術です。

C#での暗号化・復号化を理解するためには、まず基本的な暗号方式の種類や暗号強度に影響を与える要素を押さえておくことが重要です。

ここでは、対称鍵方式と非対称鍵方式の違い、そして暗号強度を左右する主な要素について詳しく解説します。

対称鍵方式と非対称鍵方式の違い

暗号方式は大きく分けて「対称鍵方式」と「非対称鍵方式」の2種類があります。

どちらもデータを暗号化し、復号化するための鍵を使いますが、その鍵の使い方に違いがあります。

対称鍵方式

対称鍵方式は、暗号化と復号化に同じ鍵を使う方式です。

つまり、送信者と受信者が同じ秘密の鍵を共有している必要があります。

代表的なアルゴリズムにAES(Advanced Encryption Standard)があります。

• 特徴
  • 処理速度が速いので大量データの暗号化に向いています
  • 鍵の管理が難しい点があります。鍵を安全に共有・保管しなければなりません
  • 鍵が漏洩すると通信内容がすべて解読されてしまいます

非対称鍵方式

非対称鍵方式は、公開鍵と秘密鍵のペアを使う方式です。

公開鍵は誰でも入手可能で、これで暗号化したデータは対応する秘密鍵でのみ復号化できます。

代表的なアルゴリズムにRSAがあります。

• 特徴
  • 鍵の共有が容易です。公開鍵は自由に配布でき、秘密鍵は厳重に管理します
  • 処理速度は対称鍵方式に比べて遅いので、大量データの暗号化には不向きです
  • 主にセッションキーの安全な共有やデジタル署名に使われます

暗号強度を左右する要素

暗号の安全性は単にアルゴリズムの種類だけでなく、いくつかの要素によって大きく左右されます。

ここでは特に重要な「キー長」「暗号モード」「パディング方式」について説明します。

キー長

キー長は暗号化に使う鍵のビット数を指します。

一般的にキー長が長いほど解読が困難になり、暗号強度が高まります。

• AESの場合

AESは128ビット、192ビット、256ビットのキー長をサポートしています。

256ビットは最も強力ですが、処理速度は128ビットに比べてわずかに遅くなります。

• RSAの場合

RSAは1024ビット、2048ビット、4096ビットなどのキー長があります。

2048ビット以上が現在の標準的な安全基準です。

キー長が長いほど安全ですが、計算コストが増大します。

• 注意点

キー長が長いほど安全ですが、処理速度やシステムリソースの消費も増えるため、用途に応じて適切な長さを選ぶことが重要です。

暗号モード

暗号モードは、ブロック暗号(AESなど)で複数のブロックをどのように処理するかを決める方式です。

モードによって安全性や性能、使い勝手が変わります。

代表的な暗号モードには以下があります。

• ECB(Electronic Codebook)

各ブロックを独立して暗号化します。

単純ですが、同じ平文ブロックは同じ暗号文になるため、パターンが漏れるリスクがあります。

推奨されません。

• CBC(Cipher Block Chaining)

前の暗号文ブロックを次のブロックの暗号化に利用します。

IV(初期化ベクトル)が必要で、パターンの漏洩を防ぎます。

多くの用途で使われています。

• GCM(Galois/Counter Mode)

暗号化と認証を同時に行うモードです。

改ざん検知が可能で、性能も高いため近年の推奨モードです。

• CTR(Counter Mode)

カウンター値を使ってストリーム暗号のように動作します。

並列処理が可能で高速ですが、IVの管理が重要です。

パディング方式

ブロック暗号は固定長のブロック単位で処理するため、平文の長さがブロックサイズの倍数でない場合はパディング(余分なデータの追加)が必要です。

パディング方式によって復号時の正確なデータ復元が可能になります。

代表的なパディング方式は以下の通りです。

• PKCS#7

最も一般的なパディング方式です。

パディングのバイト数を値として埋め込みます。

復号時にパディングの長さを判別できます。

• Zeros

余った部分をゼロで埋めます。

テキストデータ以外では誤判定のリスクがあるため注意が必要です。

• ANSIX923

パディングの最後のバイトにパディング長を入れ、それ以外はゼロで埋めます。

• ISO10126

パディング部分をランダムな値で埋め、最後のバイトにパディング長を入れます。

パディングの選択は、使用する暗号ライブラリやプロトコルの仕様に合わせることが重要です。

これらの基礎知識を理解しておくことで、C#でAESやRSAを使った暗号化・復号化を実装する際に、適切なアルゴリズムやパラメータを選択しやすくなります。

次のステップでは、具体的なAESの仕様やC#での実装方法について詳しく見ていきます。

AESの基本仕様

ブロックサイズとラウンド数

AES(Advanced Encryption Standard)は、米国国立標準技術研究所(NIST)によって標準化された対称鍵暗号方式です。

AESは固定のブロックサイズと可変のキー長を持ち、これらに応じてラウンド数が決まります。

• ブロックサイズ

AESのブロックサイズは常に128ビット(16バイト)です。

これは、暗号化や復号化の単位となるデータの大きさを意味します。

どのキー長を使ってもブロックサイズは変わりません。

• キー長

AESは3種類のキー長をサポートしています。

128ビット、192ビット、256ビットです。

キー長が長いほど安全性が高まりますが、処理にかかるコストも増加します。

• ラウンド数

ラウンドとは、暗号化処理の繰り返し回数のことです。

AESは以下のようにキー長に応じてラウンド数が変わります。

ラウンドごとに複雑な変換(SubBytes、ShiftRows、MixColumns、AddRoundKey)が行われ、これにより平文が強力に暗号化されます。

CBC・GCMなど主要モードの特徴

AESはブロック暗号であるため、単独ではブロック単位の暗号化しかできません。

複数のブロックを安全に処理するために「暗号モード」が使われます。

代表的なモードにはCBCとGCMがあります。

• CBC(Cipher Block Chaining)モード

CBCは各ブロックの暗号化に前の暗号文ブロックを利用する方式です。

最初のブロックには初期化ベクトル(IV)を使います。

これにより、同じ平文でも異なる暗号文が生成され、パターンの漏洩を防ぎます。

• 特徴
• IVは必ずランダムかつ一意である必要があります
• 復号時は暗号文の順序が重要で、並列処理が難しいです
• 改ざん検知機能はありません
• GCM(Galois/Counter Mode)モード

GCMはカウンターモード(CTR)に認証機能を加えたモードで、暗号化と同時にデータの改ざん検知が可能です。

高速かつ安全性が高いため、近年のネットワーク通信やクラウドサービスで広く使われています。

• 特徴
• 並列処理が可能で高速
• 認証タグを生成し、改ざんを検知できます
• IVの管理が重要で、再利用は絶対に避ける必要があります

AESが選ばれる理由

AESは世界中で広く採用されている理由がいくつかあります。

• 高い安全性

AESは長期間にわたり解析されてきましたが、現在も実用的な攻撃は知られていません。

特に256ビットキーは非常に強力で、量子コンピュータに対しても耐性を持つと期待されています。

• 高速な処理性能

AESはハードウェアレベルでの最適化が進んでおり、多くのCPUにAES-NI(AES New Instructions)という専用命令セットが搭載されています。

これによりソフトウェア実装よりも高速に暗号化・復号化が可能です。

• 標準化と互換性

AESは国際標準(FIPS 197)として認定されており、多くのプラットフォームやライブラリでサポートされています。

これにより異なるシステム間でも互換性が確保されやすいです。

• 柔軟なキー長とモード選択

128、192、256ビットのキー長を選べるため、用途やセキュリティ要件に応じて調整できます。

また、CBCやGCMなど複数の暗号モードが利用可能で、用途に応じた最適なモードを選べます。

• 広範な利用実績

政府機関、金融機関、クラウドサービスなど、セキュリティが厳しい分野でも採用されているため、信頼性が高いです。

これらの理由から、C#をはじめとした多くの開発環境でAESは標準的な対称鍵暗号として選ばれています。

C#でのAES実装ポイント

Aesクラスの主なプロパティ

C#でAES暗号化を行う際は、System.Security.Cryptography名前空間にあるAesクラスを利用します。

このクラスはAESの設定や暗号化・復号化処理を簡単に扱えるように設計されています。

主なプロパティは以下の通りです。

• Key

暗号化・復号化に使う秘密鍵のバイト配列です。

128、192、256ビットの長さが可能です。

外部から設定することも、GenerateKey()で自動生成することもできます。

• IV(Initialization Vector)

初期化ベクトルで、CBCやGCMなどのモードで使われます。

暗号化のたびに異なる値を使うことで、同じ平文でも異なる暗号文を生成します。

GenerateIV()で自動生成可能です。

• Mode

暗号モードを指定します。

デフォルトはCipherMode.CBCです。

CipherMode.CBC、CipherMode.ECB、CipherMode.CFBなどが利用可能ですが、セキュリティ面からCBCやGCM(.NET 5以降でサポート)を推奨します。

• Padding

パディング方式を指定します。

PaddingMode.PKCS7が一般的です。

NoneやZerosなどもありますが、通常はPKCS7を使います。

• BlockSize

ブロックサイズをビット単位で指定します。

AESは固定で128ビットです。

変更はできませんが、プロパティとして存在します。

これらのプロパティを適切に設定することで、安全かつ効率的なAES暗号化が可能です。

キーとIVの生成

AESの安全性を保つためには、キーとIVの生成が非常に重要です。

C#のAesクラスはGenerateKey()とGenerateIV()メソッドで安全な乱数を使った生成をサポートしています。

using System;
using System.Security.Cryptography;
class Program
{
    static void Main()
    {
        using (Aes aes = Aes.Create())
        {
            aes.GenerateKey();
            aes.GenerateIV();
            Console.WriteLine("生成されたキー(Base64): " + Convert.ToBase64String(aes.Key));
            Console.WriteLine("生成されたIV(Base64): " + Convert.ToBase64String(aes.IV));
        }
    }
}

生成されたキー(Base64): xc5Em+AtEMJZ0uVhk6hBJ134pSs2fLUxWrmmhd8+O8c=
生成されたIV(Base64): jwXZFJ0wp+ZZvU1Ij9DWwg==

乱数生成の注意点

• 暗号学的に安全な乱数を使うこと

キーやIVの生成にはRandomクラスのような一般的な乱数生成器は使わず、RNGCryptoServiceProviderやRandomNumberGeneratorクラスを使います。

AesクラスのGenerateKey()やGenerateIV()は内部でこれらを利用しているため安全です。

• IVは毎回異なる値を使う

同じIVを複数回使うと暗号文のパターンが漏れるリスクが高まります。

特にCBCやGCMモードではIVの再利用は避けてください。

• キーの管理は厳重に

キーは秘密情報なので、メモリ上やストレージに平文で保存しないように注意します。

必要に応じて安全な保管方法を検討してください。

CryptoStreamによるストリーム暗号化

CryptoStreamクラスは、ストリームに対して暗号化や復号化を行うための便利なクラスです。

これを使うことで、ファイルやメモリストリームに対して効率的にAES暗号化処理ができます。

以下は文字列をAESで暗号化し、復号化するサンプルコードです。

using System;
using System.IO;
using System.Security.Cryptography;
using System.Text;
class Program
{
    static void Main()
    {
        string plainText = "これはテストメッセージです。";
        using (Aes aes = Aes.Create())
        {
            aes.GenerateKey();
            aes.GenerateIV();
            byte[] encrypted = EncryptStringToBytes(plainText, aes.Key, aes.IV);
            string decrypted = DecryptStringFromBytes(encrypted, aes.Key, aes.IV);
            Console.WriteLine("元の文字列: " + plainText);
            Console.WriteLine("復号化後の文字列: " + decrypted);
        }
    }
    static byte[] EncryptStringToBytes(string plainText, byte[] key, byte[] iv)
    {
        using (Aes aes = Aes.Create())
        {
            aes.Key = key;
            aes.IV = iv;
            using (MemoryStream ms = new MemoryStream())
            using (ICryptoTransform encryptor = aes.CreateEncryptor())
            using (CryptoStream cs = new CryptoStream(ms, encryptor, CryptoStreamMode.Write))
            using (StreamWriter sw = new StreamWriter(cs, Encoding.UTF8))
            {
                sw.Write(plainText);
                sw.Flush();
                cs.FlushFinalBlock();
                return ms.ToArray();
            }
        }
    }
    static string DecryptStringFromBytes(byte[] cipherText, byte[] key, byte[] iv)
    {
        using (Aes aes = Aes.Create())
        {
            aes.Key = key;
            aes.IV = iv;
            using (MemoryStream ms = new MemoryStream(cipherText))
            using (ICryptoTransform decryptor = aes.CreateDecryptor())
            using (CryptoStream cs = new CryptoStream(ms, decryptor, CryptoStreamMode.Read))
            using (StreamReader sr = new StreamReader(cs, Encoding.UTF8))
            {
                return sr.ReadToEnd();
            }
        }
    }
}

元の文字列: これはテストメッセージです。
復号化後の文字列: これはテストメッセージです。

このコードでは、CryptoStreamを使ってメモリ上のストリームに対して暗号化・復号化を行っています。

StreamWriterとStreamReaderを使うことで文字列の入出力が簡単にできます。

バッファサイズとパフォーマンス

CryptoStreamを使う際のバッファサイズはパフォーマンスに影響します。

デフォルトのバッファサイズは4096バイトですが、処理するデータ量や環境によって調整が可能です。

• 大きなバッファサイズ

大きなバッファを使うとI/O回数が減り高速化が期待できますが、メモリ消費が増えます。

• 小さなバッファサイズ

メモリ消費は抑えられますが、I/O回数が増えて処理が遅くなる可能性があります。

ファイルの暗号化など大容量データを扱う場合は、バッファサイズを適切に設定してパフォーマンスを最適化してください。

AES暗号文のBase64エンコード

暗号化したバイト列はバイナリデータなので、そのままテキストとして扱うことはできません。

ファイル保存やネットワーク送信時にはBase64エンコードして文字列化するのが一般的です。

byte[] encryptedBytes = EncryptStringToBytes(plainText, key, iv);
string base64Encrypted = Convert.ToBase64String(encryptedBytes);
Console.WriteLine("Base64エンコードされた暗号文: " + base64Encrypted);

復号化時はBase64文字列をバイト配列に戻してから復号化します。

byte[] encryptedBytes = Convert.FromBase64String(base64Encrypted);
string decryptedText = DecryptStringFromBytes(encryptedBytes, key, iv);

Base64エンコードはデータサイズを約33%増加させますが、テキストとして扱いやすくなるため、ログ出力やJSON、XMLなどのテキストベースのフォーマットで暗号文を扱う際に便利です。

キー管理の実践的アプローチ

暗号化の安全性は、アルゴリズムの強度だけでなく、キーの管理方法に大きく依存します。

C#アプリケーションでAESやRSAのキーを安全に扱うためには、適切な保存方法やアクセス制御、運用ルールを設けることが重要です。

ここでは実務で役立つキー管理の方法を具体的に説明します。

キーファイル保存とアクセス権設定

暗号鍵をファイルとして保存する場合、ファイルの保護が最優先です。

以下のポイントを押さえてください。

• 保存場所の選定

キーファイルはアプリケーションの実行環境内でも、アクセスが制限された安全なディレクトリに保存します。

例えばWindowsの%APPDATA%やLinuxの/etc/配下など、一般ユーザーが直接アクセスしにくい場所が望ましいです。

• ファイルシステムのアクセス権設定

キーファイルに対しては、読み取り・書き込み権限を必要最小限のユーザーやプロセスに限定します。

WindowsならNTFSのアクセス制御リスト(ACL)を使い、Linuxならchmod 600などで権限を設定します。

• 暗号化して保存

キーファイル自体を暗号化して保存する方法もあります。

例えば、Windows環境ならDPAPI(Data Protection API)を使ってユーザーやマシンに紐づけて暗号化できます。

これにより、ファイルが盗まれても簡単には復号できません。

• バックアップと復元

キーファイルのバックアップは必須ですが、バックアップ先も同様に厳重に管理します。

復元時に誤って権限を緩めないよう注意が必要です。

環境変数・Secrets Managerの活用

アプリケーションの設定やキーを環境変数で管理する方法もあります。

特にクラウド環境やコンテナ化された環境で有効です。

• 環境変数の利点
  • ソースコードや設定ファイルにキーを埋め込まないため、漏洩リスクが減ります
  • デプロイ時に環境ごとに異なるキーを簡単に切り替えられます
• 注意点
  • OSやホストの管理者権限を持つユーザーは環境変数を参照可能なので、アクセス制御が重要です
  • ログに環境変数の内容が出力されないように注意します
• クラウドのSecrets Manager

AWS Secrets Manager、Azure Key Vault、Google Cloud Secret Managerなどのマネージドサービスを利用すると、キーの安全な保管とアクセス制御、監査ログの取得が容易になります。

• 特徴
• キーの自動ローテーション機能を備えていることが多い
• アクセス権限を細かく設定可能です
• API経由でアプリケーションから安全にキーを取得できます
• C#での利用例

Azure Key VaultならAzure.Security.KeyVault.Secretsパッケージを使い、認証情報を設定してキーを取得します。

HSMやKMS連携の選択肢

より高度なセキュリティが求められる場合は、ハードウェアセキュリティモジュール(HSM)やクラウドのキー管理サービス(KMS)と連携する方法があります。

• HSM(Hardware Security Module)

専用のハードウェアでキーを生成・保管し、暗号処理もHSM内で行います。

キーは外部に出ないため、物理的な盗難や不正アクセスに強いです。

• KMS(Key Management Service)

クラウドプロバイダーが提供するサービスで、HSMをバックエンドに持つことが多いです。

API経由でキーの生成、暗号化、復号化を行います。

• メリット
  • キーの漏洩リスクを大幅に低減
  • キーのライフサイクル管理(生成、ローテーション、破棄)が容易
  • 監査ログやアクセス制御が充実
• C#での連携例

AWS KMSならAmazon.KeyManagementService SDKを使い、暗号化・復号化をAPIで実行します。

Azure Key Vaultも同様にSDKが提供されています。

キーローテーションの手順

キーは長期間同じものを使い続けると、漏洩リスクや暗号強度の低下が懸念されます。

定期的なキーローテーション(交換)が推奨されます。

スケジュール管理

• ローテーション頻度の決定

業界標準や規制に基づき、半年から1年程度を目安に設定することが多いです。

重要度が高いシステムではより短期間に設定します。

• 自動化の検討

Secrets ManagerやKMSの自動ローテーション機能を活用すると、手動ミスを減らせます。

自動化できない場合は運用手順書を整備し、担当者が確実に実施できるようにします。

• 通知と監査

ローテーションの実施前後に関係者へ通知し、監査ログを残すことが望ましいです。

旧キーの扱い

• 旧キーの保管期間

ローテーション後も、旧キーは一定期間保管します。

これは、ローテーション前に暗号化されたデータの復号化に必要なためです。

• 段階的廃止

新しいキーで暗号化を行い、旧キーは復号専用に切り替えます。

古いデータを新キーで再暗号化(再暗号化)する場合もあります。

• 安全な破棄

旧キーの保管期間が終了したら、安全に破棄します。

メモリ上のキー情報もクリアし、ストレージから完全に削除します。

• 運用上の注意

旧キーの管理も厳重に行い、誤って漏洩しないようにします。

アクセス権限は最小限に絞り、監査ログを取得します。

RSAの基本仕様

公開鍵と秘密鍵のペア構造

RSAは非対称暗号方式の代表的なアルゴリズムで、公開鍵と秘密鍵のペアを使って暗号化と復号化を行います。

このペアは数学的に密接に関連していますが、公開鍵から秘密鍵を推測することは非常に困難です。

• 公開鍵(Public Key)

公開鍵は自由に配布できる鍵で、主にデータの暗号化やデジタル署名の検証に使われます。

公開鍵は2つの大きな整数、すなわち「モジュラス(n)」と「公開指数(e)」で構成されます。

• 秘密鍵(Private Key)

秘密鍵は厳重に管理されるべき鍵で、暗号化されたデータの復号化やデジタル署名の生成に使われます。

秘密鍵は公開鍵の情報に加え、「秘密指数(d)」やその他のパラメータを含みます。

RSAの安全性は、巨大な素数の積であるモジュラスの因数分解の困難さに基づいています。

秘密鍵はこの因数分解に必要な情報を持っているため、秘密鍵が漏れると暗号は破られてしまいます。

キー長による安全性と速度のトレードオフ

RSAのキー長はビット単位で表され、一般的には1024ビット、2048ビット、4096ビットなどが使われます。

キー長は安全性と処理速度のバランスに大きく影響します。

• 安全性

キー長が長いほど、因数分解が困難になり安全性が高まります。

現在では1024ビットは安全とは言えず、最低でも2048ビット以上が推奨されています。

4096ビットはさらに強力ですが、将来的な量子コンピュータの脅威にも備える意味があります。

• 処理速度

キー長が長くなると、暗号化・復号化の計算コストが増加します。

特に復号化(秘密鍵操作)は公開鍵操作よりも重いため、パフォーマンスに影響が出やすいです。

• 実用上の選択

多くのシステムでは2048ビットキーが標準的に使われています。

高いセキュリティが求められる場合は4096ビットを検討しますが、パフォーマンス要件も考慮する必要があります。

Padding方式比較

RSAはブロック暗号ではなく、直接大きな数値の演算を行うため、平文の長さや構造に制限があります。

そのため、暗号化前に「パディング」と呼ばれる処理を施し、セキュリティを強化します。

代表的なパディング方式にはOAEPとPKCS#1 v1.5があります。

OAEP(Optimal Asymmetric Encryption Padding)

OAEPはRSA暗号化における推奨されるパディング方式で、セキュリティ強化のために設計されました。

OAEPはメッセージにランダムな値を加え、暗号文のパターンを隠すことで、選択平文攻撃(Chosen Plaintext Attack)や中間者攻撃に対して強い耐性を持ちます。

• 特徴
  • メッセージの長さ制限がPKCS#1 v1.5より厳しいが、より安全
  • ランダム性を導入するため、同じ平文でも毎回異なる暗号文が生成されます
  • SHA-1やSHA-256などのハッシュ関数を使ってマスク生成関数(MGF)を実装
• 利用例

.NETのRSAEncryptionPadding.OaepSHA256などで指定可能です。

• メリット
  • 現代のセキュリティ要件に適合
  • 攻撃に対する耐性が高いでしょう
• デメリット
  • 実装がやや複雑
  • 一部の古いシステムやプロトコルでは非対応

PKCS#1 v1.5

PKCS#1 v1.5はRSA暗号化の初期から使われているパディング方式で、互換性が高い反面、いくつかのセキュリティ上の弱点があります。

• 特徴
  • メッセージに固定のパディングパターンを付加します
  • 同じ平文は同じ暗号文になる可能性があります
  • 選択平文攻撃に対して脆弱な場合があります
• 利用例

.NETのRSAEncryptionPadding.Pkcs1で指定可能です。

• メリット
  • 古いシステムやプロトコルとの互換性が高いでしょう
  • 実装がシンプル
• デメリット
  • セキュリティ上のリスクがあるため、新規開発では推奨されない
  • 攻撃に対する耐性がOAEPより低いでしょう

RSA暗号化をC#で実装する際は、可能な限りOAEPを使うことが望ましいです。

特にRSAEncryptionPadding.OaepSHA256は安全性と互換性のバランスが良く、多くの環境で利用されています。

C#でのRSA実装ポイント

RSA.Createでのキーペア生成

C#でRSAの鍵ペアを生成するには、RSA.Create()メソッドを使います。

このメソッドはRSAアルゴリズムのインスタンスを生成し、デフォルトで2048ビットの鍵長を持つキーペアを作成します。

必要に応じて鍵長を指定することも可能です。

using System;
using System.Security.Cryptography;
class Program
{
    static void Main()
    {
        using (RSA rsa = RSA.Create(2048)) // 2048ビットの鍵ペアを生成
        {
            RSAParameters publicKey = rsa.ExportParameters(false); // 公開鍵のみ
            RSAParameters privateKey = rsa.ExportParameters(true); // 秘密鍵を含む
            Console.WriteLine("公開鍵のモジュラス長: " + publicKey.Modulus.Length * 8 + "ビット");
        }
    }
}

公開鍵のモジュラス長: 2048ビット

• ExportParameters(false)は公開鍵のみを取得し、ExportParameters(true)は秘密鍵を含む全パラメータを取得します
• 鍵長はRSA.Create(int keySize)の引数で指定可能で、2048ビット以上を推奨します

公開鍵配布とインポート

公開鍵は暗号化や署名検証に使うため、自由に配布できますが、改ざんされないように注意が必要です。

C#では公開鍵をXML形式やPEM形式でエクスポート・インポートできます。

• 公開鍵のエクスポート(XML形式)

string publicKeyXml = rsa.ToXmlString(false); // 公開鍵のみ
Console.WriteLine(publicKeyXml);

• 公開鍵のインポート(XML形式)

using (RSA rsa = RSA.Create())
{
    rsa.FromXmlString(publicKeyXml);
    // ここで暗号化や検証処理を行う
}

• PEM形式の利用

.NET 5以降ではExportSubjectPublicKeyInfo()やImportSubjectPublicKeyInfo()を使い、PEM形式の公開鍵を扱えます。

PEMはBase64エンコードされたテキスト形式で、他のシステムとの互換性が高いです。

byte[] publicKeyBytes = rsa.ExportSubjectPublicKeyInfo();
string publicKeyPem = "-----BEGIN PUBLIC KEY-----\n" +
                      Convert.ToBase64String(publicKeyBytes, Base64FormattingOptions.InsertLineBreaks) +
                      "\n-----END PUBLIC KEY-----";
Console.WriteLine(publicKeyPem);

• 配布時の注意点

公開鍵は改ざんされるとセキュリティリスクになるため、配布時はデジタル署名や証明書を使って真正性を保証することが望ましいです。

秘密鍵保護のベストプラクティス

秘密鍵はシステムの中で最も重要な情報なので、厳重に保護しなければなりません。

以下のポイントを守ることが重要です。

• メモリ上の保護

秘密鍵を平文でメモリに長時間保持しないようにします。

使用後は速やかにメモリをクリアすることが望ましいです。

• 安全なストレージ

秘密鍵はファイルに保存する場合、暗号化して保管します。

Windows環境ならDPAPI(ProtectedDataクラス)を使う方法があります。

• アクセス制御

ファイルシステムのアクセス権限を最小限に設定し、秘密鍵にアクセスできるユーザーやプロセスを限定します。

• ハードウェアセキュリティモジュール(HSM)やクラウドKMSの利用

可能であれば、秘密鍵をHSMやクラウドのキー管理サービスに保管し、アプリケーションはAPI経由で暗号処理を行う方法が安全です。

• バックアップと復元

秘密鍵のバックアップは必須ですが、バックアップも同様に厳重に管理し、漏洩リスクを最小化します。

RSAEncryptionPaddingの設定

RSA暗号化・復号化時にはパディング方式を指定します。

C#のRSAEncryptionPaddingクラスで以下の方式が利用可能です。

• OAEP(Optimal Asymmetric Encryption Padding)

RSAEncryptionPadding.OaepSHA1、RSAEncryptionPadding.OaepSHA256など、ハッシュアルゴリズムを指定可能です。

セキュリティが高く推奨されます。

• PKCS#1 v1.5

RSAEncryptionPadding.Pkcs1。

互換性は高いですが、セキュリティ面でOAEPより劣ります。

byte[] encrypted = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA256);
byte[] decrypted = rsa.Decrypt(encrypted, RSAEncryptionPadding.OaepSHA256);

• 選択のポイント

新規開発ではOAEPを使い、特にOaepSHA256が推奨されます。

既存システムとの互換性が必要な場合はPKCS#1 v1.5を使うこともあります。

例外処理とログ出力

RSA暗号化処理では例外が発生する可能性があるため、適切な例外処理を行い、問題発生時に原因を特定しやすくすることが重要です。

• 主な例外
  • CryptographicException：鍵の不正、パディングエラー、データ長超過など
  • ArgumentNullException：引数がnullの場合
  • ArgumentException：不正な引数の場合
• 例外処理の例

try
{
    byte[] encrypted = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA256);
}
catch (CryptographicException ex)
{
    Console.Error.WriteLine("暗号化エラー: " + ex.Message);
    // 必要に応じてリトライや代替処理を実装
}

• ログ出力の注意点
  • 秘密鍵や平文データをログに出力しない
  • エラーメッセージは詳細すぎず、攻撃者に情報を与えないようにします
  • 監査ログとして暗号処理の成功・失敗を記録し、セキュリティ監査に役立てる

これらのポイントを守ることで、安全かつ堅牢なRSA暗号化機能をC#で実装できます。

ハイブリッド暗号化モデル

セッションキーの共有フロー

ハイブリッド暗号化モデルは、対称鍵暗号(AESなど)の高速性と非対称鍵暗号(RSAなど)の安全な鍵配送の利点を組み合わせた方式です。

主に大容量データの暗号化に対称鍵を使い、その対称鍵(セッションキー)を非対称鍵で安全に共有します。

セッションキーの共有フローは以下のようになります。

1. セッションキーの生成

送信者はランダムな対称鍵(AESキー)を生成します。

このキーは一時的に通信のためだけに使われるため「セッションキー」と呼ばれます。

2. セッションキーのRSA暗号化

送信者は受信者の公開鍵を使い、セッションキーをRSAで暗号化します。

これにより、セッションキーは安全に送信できます。

3. データのAES暗号化

送信者はセッションキーを使って、実際のメッセージデータをAESで暗号化します。

4. 暗号文と暗号化されたセッションキーの送信

送信者はAESで暗号化したデータと、RSAで暗号化したセッションキーを受信者に送ります。

5. セッションキーの復号化

受信者は自分の秘密鍵を使い、RSAで暗号化されたセッションキーを復号化します。

6. データの復号化

受信者は復号したセッションキーを使い、AES暗号文を復号化して元のメッセージを取得します。

このフローにより、セッションキーの安全な共有と高速なデータ暗号化を両立できます。

AES＋RSA連携のコード構成

C#でハイブリッド暗号化を実装する場合、以下のような構成が一般的です。

• セッションキー生成とRSA暗号化

using System;
using System.Security.Cryptography;
byte[] GenerateSessionKey()
{
    using (Aes aes = Aes.Create())
    {
        aes.KeySize = 256;
        aes.GenerateKey();
        return aes.Key;
    }
}
byte[] EncryptSessionKey(byte[] sessionKey, RSA rsaPublicKey)
{
    return rsaPublicKey.Encrypt(sessionKey, RSAEncryptionPadding.OaepSHA256);
}

• データのAES暗号化

byte[] EncryptData(string plainText, byte[] key, byte[] iv)
{
    using (Aes aes = Aes.Create())
    {
        aes.Key = key;
        aes.IV = iv;
        using (var ms = new System.IO.MemoryStream())
        using (var encryptor = aes.CreateEncryptor())
        using (var cs = new CryptoStream(ms, encryptor, CryptoStreamMode.Write))
        using (var sw = new System.IO.StreamWriter(cs))
        {
            sw.Write(plainText);
            sw.Flush();
            cs.FlushFinalBlock();
            return ms.ToArray();
        }
    }
}

• 復号化側の処理

byte[] DecryptSessionKey(byte[] encryptedSessionKey, RSA rsaPrivateKey)
{
    return rsaPrivateKey.Decrypt(encryptedSessionKey, RSAEncryptionPadding.OaepSHA256);
}
string DecryptData(byte[] cipherText, byte[] key, byte[] iv)
{
    using (Aes aes = Aes.Create())
    {
        aes.Key = key;
        aes.IV = iv;
        using (var ms = new System.IO.MemoryStream(cipherText))
        using (var decryptor = aes.CreateDecryptor())
        using (var cs = new CryptoStream(ms, decryptor, CryptoStreamMode.Read))
        using (var sr = new System.IO.StreamReader(cs))
        {
            return sr.ReadToEnd();
        }
    }
}

• 全体の流れ

1. 送信者はGenerateSessionKey()でAESキーを作成。
2. 受信者の公開鍵でEncryptSessionKey()を呼び、セッションキーを暗号化。
3. AESのIVを生成し、EncryptData()でメッセージを暗号化。
4. 受信者は秘密鍵でDecryptSessionKey()を呼び、セッションキーを復号。
5. 復号したセッションキーとIVでDecryptData()を呼び、メッセージを復号。

メッセージサイズと効率

ハイブリッド暗号化モデルは大容量データの暗号化に適していますが、メッセージサイズや処理効率に注意が必要です。

• RSAの制限

RSAは暗号化できるデータサイズに制限があります。

例えば2048ビット鍵の場合、パディングを考慮すると最大で約245バイト程度のデータしか暗号化できません。

したがって、セッションキーのような小さなデータの暗号化に限定されます。

• AESの高速性

AESは大容量データの暗号化に非常に高速で効率的です。

数MBや数GBのデータでも実用的な速度で処理できます。

• 通信データの構成

送信時には「RSAで暗号化したセッションキー」「AESの初期化ベクトル(IV)」「AESで暗号化したメッセージ本体」の3つをまとめて送る必要があります。

これにより、受信者は正しく復号できます。

• オーバーヘッド

RSA暗号化されたセッションキーは固定長(鍵長に依存)で、AESのIVは通常16バイトです。

これらはメッセージ本体に比べて小さいため、全体の通信量に与える影響は限定的です。

• パフォーマンス最適化
  • セッションキーの生成やRSA暗号化は一度だけ行い、複数のメッセージで使い回すことも可能ですが、セキュリティ上は推奨されません
  • 並列処理やストリーム処理を活用し、大容量データの暗号化・復号化を効率化できます

このように、ハイブリッド暗号化モデルは安全性と効率性を両立し、実用的な暗号通信を実現します。

追加セキュリティ強化策

デジタル署名による改ざん検知

デジタル署名は、送信されたデータが改ざんされていないことを検証するための技術です。

暗号化だけではデータの機密性は守れますが、改ざんやなりすましを防ぐには署名が必要です。

C#ではRSAやECDSAなどの非対称鍵アルゴリズムを使ってデジタル署名を実装できます。

• 仕組み

送信者は秘密鍵を使ってメッセージのハッシュ値に署名を行い、署名付きのメッセージを送信します。

受信者は送信者の公開鍵で署名を検証し、メッセージが改ざんされていないことを確認します。

• C#での例

using System;
using System.Security.Cryptography;
using System.Text;
class Program
{
    static void Main()
    {
        string message = "重要なメッセージ";
        using (RSA rsa = RSA.Create(2048))
        {
            byte[] data = Encoding.UTF8.GetBytes(message);
            // 署名生成
            byte[] signature = rsa.SignData(data, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
            // 署名検証
            bool verified = rsa.VerifyData(data, signature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
            Console.WriteLine("署名検証結果: " + verified);
        }
    }
}

署名検証結果: True

• ポイント
  • 署名は秘密鍵で生成し、公開鍵で検証します
  • ハッシュ関数はSHA-256など安全なものを使います
  • 署名が正しければ、メッセージの改ざんや送信者のなりすましを検知できます

HMACとAES‐GCMの使い分け

メッセージ認証コード(MAC)は、データの完全性と認証を保証するために使われます。

HMACとAES-GCMはどちらも認証機能を持ちますが、用途や実装方法に違いがあります。

• HMAC(Hash-based Message Authentication Code)
  • 対称鍵とハッシュ関数(SHA-256など)を使ってメッセージの認証コードを生成します
  • AESなどの暗号化とは別に、メッセージの改ざん検知用にHMACを付加する方式が一般的です
  • 実装がシンプルで、既存の暗号化方式に容易に追加可能です
• AES-GCM(Galois/Counter Mode)
  • AESの暗号化モードの一つで、暗号化と同時に認証タグを生成します
  • 認証タグにより、暗号文の改ざん検知が可能です
  • 高速かつ効率的で、ネットワーク通信などで広く使われています

• 使い分けのポイント
  • 新規開発や通信プロトコルではAES-GCMが推奨されます
  • 既存の暗号化方式に認証を追加したい場合はHMACが手軽です
  • セキュリティ要件や環境に応じて選択してください

タイムスタンプとリプレイ攻撃対策

リプレイ攻撃は、攻撃者が過去に送信された正当なメッセージを再送信し、不正な操作を行う攻撃です。

これを防ぐためにタイムスタンプや一意の識別子を使った対策が必要です。

• タイムスタンプの利用

メッセージに送信時刻を付加し、受信側で有効期限をチェックします。

期限切れのメッセージは破棄することで、古いメッセージの再利用を防ぎます。

• ノンス(Nonce)や一意識別子の利用

メッセージごとにランダムな値(ノンス)や連番、一意のIDを付与し、受信側で過去に受け取った値と照合します。

重複があればリプレイと判断して拒否します。

• C#での実装例(簡易版)

using System;
using System.Collections.Generic;
class ReplayAttackDetector
{
    private HashSet<string> receivedNonces = new HashSet<string>();
    private TimeSpan validDuration = TimeSpan.FromMinutes(5);
    public bool IsReplay(string nonce, DateTime timestamp)
    {
        if (DateTime.UtcNow - timestamp > validDuration)
        {
            return true; // タイムスタンプ期限切れ
        }
        if (receivedNonces.Contains(nonce))
        {
            return true; // ノンス重複
        }
        receivedNonces.Add(nonce);
        return false;
    }
}
class Program
{
    static void Main()
    {
        var detector = new ReplayAttackDetector();
        string nonce = Guid.NewGuid().ToString();
        DateTime timestamp = DateTime.UtcNow;
        bool isReplay = detector.IsReplay(nonce, timestamp);
        Console.WriteLine("リプレイ攻撃検知: " + isReplay); // False
        // 同じノンスを再度チェック
        isReplay = detector.IsReplay(nonce, timestamp);
        Console.WriteLine("リプレイ攻撃検知: " + isReplay); // True
    }
}

リプレイ攻撃検知: False
リプレイ攻撃検知: True

• ポイント
  • タイムスタンプは送信者と受信者の時計が同期している必要があります
  • ノンスは一意で予測不可能な値を使い、使い捨てにします
  • 受信側でノンスの管理が必要で、メモリやストレージの容量に注意してください

これらの追加セキュリティ強化策を組み合わせることで、暗号化通信の安全性をさらに高められます。

典型的な落とし穴と回避策

静的キー埋め込みの危険性

ソースコード内に暗号鍵を直接埋め込むことは非常に危険です。

静的に埋め込まれたキーは、リバースエンジニアリングやコード解析によって容易に抽出されてしまいます。

これにより、攻撃者に暗号化の秘密情報を奪われ、システム全体のセキュリティが破られるリスクが高まります。

• 問題点
  • バージョン管理システムにキーが残るため、過去のコミット履歴からもキーが漏洩する可能性があります
  • 複数の開発者やCI/CD環境にキーが広がり、管理が困難になります
  • アプリケーションの配布物にキーが含まれると、解析ツールで簡単に抽出されます
• 回避策
  • キーは環境変数や安全な設定ファイル、Secrets Managerなど外部から注入します
  • キー管理専用のサービス(KMSやHSM)を利用し、アプリケーションはAPI経由でキーを取得・利用します
  • ソースコードにキーを含めないようにコードレビューや自動スキャンを導入します

IVの再利用による情報漏えい

初期化ベクトル(IV)は、対称鍵暗号の安全性を保つために重要な役割を果たします。

特にCBCやGCMモードでは、同じキーで同じIVを複数回使うことは重大なセキュリティリスクです。

• 問題点
  • IVの再利用により、暗号文のパターンが漏れ、平文の一部が推測される可能性があります
  • GCMモードではIVの再利用が認証タグの衝突を引き起こし、改ざん検知が無効になる恐れがあります
  • 攻撃者が暗号文の一部を操作しやすくなります
• 回避策
  • IVは必ずランダムかつ一意の値を生成し、暗号化ごとに使い捨てる
  • IVの生成には暗号学的に安全な乱数生成器を使います
  • IVは暗号文と一緒に送信し、復号時に正しく利用します
  • GCMモードを使う場合は、IVの管理を特に厳重に行います

不適切な例外メッセージ

暗号化処理で発生した例外を適切に扱わないと、セキュリティ上の問題が生じることがあります。

特に例外メッセージに機密情報や内部構造が含まれると、攻撃者に有用な情報を与えてしまいます。

• 問題点
  • 詳細すぎる例外メッセージがログや画面に表示され、攻撃者に鍵の長さやアルゴリズムの種類、内部状態を推測されます
  • 例外処理が不十分でアプリケーションがクラッシュし、サービス拒否(DoS)攻撃の原因になります
  • 例外を無視して処理を続行すると、誤った復号結果やデータ破損が発生します
• 回避策
  • 例外メッセージはユーザー向けには一般的なエラー内容にとどめ、詳細は内部ログに限定します
  • 例外処理を適切に行い、必要に応じてリトライや代替処理を実装します
  • ログには機密情報を含めず、アクセス制御を強化します
  • セキュリティ監査の観点から、例外発生時の状況を記録し、分析可能にします

これらの落とし穴を理解し、適切な対策を講じることで、C#での暗号化実装の安全性を大幅に向上させられます。

パフォーマンスと最適化

バッチ処理と並列化

大量のデータを暗号化・復号化する場合、単一の処理で逐次的に行うと時間がかかり、システム全体のパフォーマンスに影響を与えます。

そこで、バッチ処理や並列化を活用して効率化を図ることが重要です。

• バッチ処理

データを複数のチャンク(塊)に分割し、一括で処理する方法です。

例えば、ファイルを一定サイズのブロックに分割し、それぞれを順次暗号化します。

これによりメモリ使用量を制御しつつ、処理の進捗管理がしやすくなります。

• 並列化

複数のCPUコアを活用して同時に複数の暗号化処理を行う方法です。

C#ではParallel.ForやTaskを使って簡単に並列処理を実装できます。

using System;
using System.Threading.Tasks;
class Program
{
    static void Main()
    {
        byte[][] dataChunks = GetDataChunks(); // 複数のデータチャンクを取得
        Parallel.For(0, dataChunks.Length, i =>
        {
            byte[] encrypted = EncryptChunk(dataChunks[i]);
            // 暗号化結果の保存や処理
        });
    }
    static byte[] EncryptChunk(byte[] data)
    {
        // AES暗号化処理(省略)
        return data; // 仮の戻り値
    }
    static byte[][] GetDataChunks()
    {
        // データ分割処理(省略)
        return new byte[10][];
    }
}

• 注意点
  • 並列処理時はスレッドセーフな設計が必要です
  • リソース競合やメモリ使用量の増加に注意し、適切なスレッド数を設定します
  • 並列化の効果はデータサイズや環境によって異なるため、ベンチマークで最適値を探ることが重要です

ストリームサイズ別ベンチマーク

暗号化処理のパフォーマンスは、処理するデータのサイズやバッファサイズによって大きく変わります。

適切なバッファサイズを選ぶことで、I/O回数を減らし効率的に処理できます。

• 小さいストリームサイズ

数KB程度の小さなデータでは、バッファサイズを大きくしても効果は限定的です。

むしろバッファサイズが大きすぎるとメモリの無駄遣いになります。

• 中程度のストリームサイズ

数MB程度のデータでは、4KB〜64KB程度のバッファサイズがバランス良く、処理速度が向上します。

• 大きいストリームサイズ

数百MB以上の大容量データでは、64KB〜1MB程度のバッファサイズを使い、I/O回数を減らすことが効果的です。

• ベンチマーク例

• 実践ポイント
  • 実際の環境で複数のバッファサイズを試し、最適な値を見つける
  • メモリ制約が厳しい場合は小さめのバッファを選択
  • ネットワークやディスクI/Oの特性も考慮します

GPUやAES-NIの活用

暗号化処理の高速化には、ハードウェア支援を活用する方法があります。

特にAES-NIやGPUを使ったアクセラレーションが効果的です。

• AES-NI(Advanced Encryption Standard New Instructions)

IntelやAMDのCPUに搭載されているAES専用命令セットで、AES暗号化・復号化をハードウェアレベルで高速化します。

C#のAesクラスはOSやランタイムがAES-NIをサポートしていれば自動的に利用します。

• メリット
• ソフトウェア実装に比べて数倍高速
• CPU負荷が低減し、他の処理にリソースを割けます
• セキュリティ面でも安全な実装
• 確認方法

WindowsではSystem.Security.Cryptography名前空間のAesクラスを使うだけでAES-NIが有効になります。

特別な設定は不要です。

• GPUアクセラレーション

GPUは並列処理に優れており、大量のデータを高速に処理できます。

CUDAやOpenCLを使った暗号化ライブラリを利用することで、AESなどの暗号処理をGPUで実行可能です。

• メリット
  • 大規模データのバッチ処理で大幅な高速化が期待できます
  • 並列度が高い処理に適しています
• 課題
  • GPUプログラミングの知識が必要でしょう
  • データ転送のオーバーヘッドが発生する場合があります
  • C#から利用するにはラッパーや専用ライブラリが必要でしょう
• まとめ
  • 一般的なアプリケーションではAES-NIの恩恵を受けるだけで十分な高速化が可能です
  • 大規模な暗号処理や特殊用途ではGPUアクセラレーションを検討する価値があります
  • ハードウェア支援の有無は環境依存なので、実行環境での動作確認が重要でしょう

これらのパフォーマンス最適化手法を組み合わせることで、C#アプリケーションの暗号化処理を効率的かつ高速に実装できます。

テストと検証手法

既知平文攻撃シナリオでの動作確認

既知平文攻撃(Known-Plaintext Attack)は、攻撃者が暗号化されたデータの一部の平文と対応する暗号文を知っている状況を想定した攻撃手法です。

暗号化実装の安全性を検証するために、このシナリオを模擬したテストを行うことが重要です。

• テストの目的
  • 暗号化アルゴリズムが同じ平文に対して毎回異なる暗号文を生成しているか確認します
  • IVやパディングの適切な利用により、パターンの漏洩が防止されているか検証します
  • 復号処理が正確に行われ、既知の平文が正しく復元されるか確認します
• 具体的なテスト方法

1. 同じ平文を複数回暗号化し、生成される暗号文が異なることを確認します。
2. 既知の平文と暗号文のペアを用いて復号化を行い、平文が正しく復元されるか検証します。
3. 改ざんされた暗号文を復号化し、例外やエラーが適切に発生するか確認します。

• C#での例

string plainText = "テストメッセージ";
using (Aes aes = Aes.Create())
{
    aes.GenerateKey();
    byte[] encrypted1 = Encrypt(plainText, aes.Key);
    byte[] encrypted2 = Encrypt(plainText, aes.Key);
    bool areDifferent = !encrypted1.SequenceEqual(encrypted2);
    Console.WriteLine("同じ平文の暗号文が異なるか: " + areDifferent);
}
byte[] Encrypt(string text, byte[] key)
{
    using (Aes aes = Aes.Create())
    {
        aes.Key = key;
        aes.GenerateIV();
        using (var ms = new MemoryStream())
        {
            ms.Write(aes.IV, 0, aes.IV.Length); // IVを先頭に付加
            using (var cs = new CryptoStream(ms, aes.CreateEncryptor(), CryptoStreamMode.Write))
            using (var sw = new StreamWriter(cs))
            {
                sw.Write(text);
            }
            return ms.ToArray();
        }
    }
}

• 期待結果

同じ平文でも暗号文が異なり、IVの再利用がないことが確認できます。

交差検証用テストベクトル

テストベクトルは、暗号アルゴリズムの実装が正しいかどうかを検証するための既知の入力と出力の組み合わせです。

標準化団体や暗号ライブラリが提供するテストベクトルを使うことで、実装の互換性や正確性を保証できます。

• 利用方法
  • 既知の平文、キー、IVを使って暗号化を行い、得られた暗号文がテストベクトルの期待値と一致するか確認します
  • 逆に、テストベクトルの暗号文を復号化し、平文が一致するか検証します
• 代表的なテストベクトル例
  • AESのNIST公式テストベクトル(CBC、GCMなど各モード対応)
  • RSAのPKCS#1標準テストベクトル
• C#での活用例

テストベクトルの値をハードコードまたは外部ファイルから読み込み、暗号化・復号化処理の結果と比較します。

// 例: AES CBCモードのテストベクトル
byte[] key = Convert.FromBase64String("Base64エンコードされたキー");
byte[] iv = Convert.FromBase64String("Base64エンコードされたIV");
byte[] expectedCipher = Convert.FromBase64String("期待される暗号文");
byte[] actualCipher = EncryptWithAesCbc(plainText, key, iv);
bool isMatch = expectedCipher.SequenceEqual(actualCipher);
Console.WriteLine("テストベクトル一致: " + isMatch);

• メリット
  • 実装の誤りを早期に発見できます
  • 他の実装との互換性を確保できます
  • セキュリティ監査や品質保証に役立ちます

単体テストと統合テストの観点

暗号化機能のテストは単体テストと統合テストの両面から行う必要があります。

• 単体テスト
  • 個々の暗号化・復号化メソッドが正しく動作するか検証
  • 異常系テスト(無効なキー、破損したデータ、パディングエラーなど)を含みます
  • テストベクトルを使った正確性の確認
  • 例外処理やエラーハンドリングの検証
• 統合テスト
  • 暗号化機能が他のシステムコンポーネントと連携して正しく動作するか確認
  • 実際の通信やファイル入出力を含むシナリオテスト
  • キー管理やセッション管理との連携検証
  • パフォーマンスやスケーラビリティの評価
• テスト自動化のポイント
  • CI/CDパイプラインに暗号化テストを組み込み、継続的に品質を保証
  • テスト結果のログやレポートを詳細に記録し、問題発生時に迅速に対応
  • セキュリティ要件に基づくテストケースを網羅的に作成

これらのテストと検証手法を組み合わせることで、C#で実装した暗号化機能の信頼性と安全性を高められます。

運用フェーズのチェックリスト

ログの機微情報マスキング

運用中のシステムではログがトラブルシューティングや監査に不可欠ですが、ログに機微情報が含まれると情報漏洩のリスクが高まります。

暗号化システムのログには特に注意が必要です。

• 機微情報の例
  • 平文データや暗号鍵、IVなどの秘密情報
  • ユーザーの個人情報や認証トークン
  • エラーメッセージに含まれる内部構造やスタックトレース
• マスキングの方法
  • ログ出力前に平文や秘密情報をマスク(例：“や部分的に伏せ字)します
  • 例外メッセージは詳細を内部ログに限定し、ユーザー向けログは一般的なエラー内容にとどめる
  • ログ収集ツールやSIEMでのフィルタリング設定を活用します
• 実装例(C#)

string sensitiveData = "ユーザーのパスワード1234";
string maskedData = MaskSensitiveInfo(sensitiveData);
Console.WriteLine("ログ出力: " + maskedData);
string MaskSensitiveInfo(string input)
{
    if (string.IsNullOrEmpty(input)) return input;
    return input.Length <= 4 ? "****" : input.Substring(0, 2) + "****" + input.Substring(input.Length - 2);
}

• ポイント
  • ログに含める情報は最小限にし、必要な情報だけを記録します
  • ログファイルのアクセス権限を厳格に管理し、不正アクセスを防止します
  • 定期的にログの内容をレビューし、機微情報が含まれていないかチェックします

監査証跡の保存期間

監査証跡はセキュリティインシデントの調査やコンプライアンス対応に不可欠です。

暗号化システムの運用では、ログや操作履歴、キー管理履歴などを適切に保存し、管理する必要があります。

• 保存期間の決定基準
  • 法令や業界規制(例：個人情報保護法、金融規制)に準拠します
  • 企業のセキュリティポリシーやリスク評価に基づく
  • インシデント対応やフォレンジック調査に必要な期間を考慮
• 一般的な保存期間例
  • 6ヶ月〜3年程度が多いが、規制によっては5年以上の場合もあります
  • 保存期間終了後は安全に削除またはアーカイブします
• 管理方法
  • ログの改ざん防止のため、WORM(Write Once Read Many)ストレージやデジタル署名を活用
  • 保存場所のアクセス制御を厳格に設定
  • 定期的なバックアップと復元テストを実施

障害時の復旧フロー

バージョン互換性と移行戦略

.NET Frameworkと.NET CoreのAPI差異

C#で暗号化を実装する際、.NET Frameworkと.NET Core(および.NET 5以降)ではAPIの仕様やサポート状況に違いがあります。

これらの差異を理解し、移行や互換性対応を行うことが重要です。

• APIの違い
  • .NET FrameworkではSystem.Security.Cryptography名前空間のクラスが古い実装で提供されており、RSACryptoServiceProviderやAesCryptoServiceProviderなどのプロバイダー依存のクラスが多用されます
  • .NET Core以降はRSA.Create()やAes.Create()などのファクトリーメソッドが推奨され、よりモダンでクロスプラットフォーム対応の実装が提供されています
  • .NET CoreではRSAやAesの派生クラスがOSのネイティブAPI(WindowsならCNG、LinuxならOpenSSL)を利用するため、パフォーマンスやセキュリティが向上しています
• サポートされる機能の違い
  • .NET CoreはRSAEncryptionPadding.OaepSHA256などの新しいパディング方式をサポートしていますが、.NET Frameworkの古いバージョンでは対応していない場合があります
  • AesGcmやAesCcmなどの認証付き暗号モードは.NET Core 3.0以降で利用可能で、.NET Frameworkには存在しません
• 移行時の注意点
  • 既存の.NET Frameworkコードを.NET Coreに移行する際は、暗号APIの呼び出し方やパディング設定を見直す必要があります
  • 互換性のために、ToXmlStringやFromXmlStringメソッドの代替手段(PEM形式の鍵管理など)を検討することが推奨されます
  • クロスプラットフォーム対応を考慮し、OS依存のAPI呼び出しを避ける設計が望ましいです

旧システムからのキー移行

既存システムから新システムへ暗号鍵を移行する際は、セキュリティを損なわずに安全かつ確実に行うことが求められます。

• キーのエクスポート形式
  • 旧システムで使用している鍵の形式(XML、PEM、DERなど)を確認し、新システムで対応可能な形式に変換します
  • 可能であれば、標準的なPEMやPKCS#8形式に変換し、互換性を高めることが望ましいです
• 安全な移行手順

1. 鍵を安全な環境でエクスポートし、暗号化やパスワード保護を施します。
2. 移行先システムに安全なチャネル(VPNや専用線など)で転送。
3. 移行後、鍵の整合性と動作確認を実施。
4. 移行完了後は旧システムの鍵を安全に破棄またはアーカイブ。

• 移行時のリスク管理
  • 秘密鍵の漏洩リスクを最小化するため、移行作業は権限を限定した担当者が行います
  • 移行中の鍵のバックアップを確実に取り、万が一の障害に備えます
  • 移行後は新システムでのキー管理ポリシーに従い、適切なアクセス制御を設定
• 再暗号化の検討
  • 旧システムの鍵をそのまま使い続ける場合、将来的なセキュリティリスクを考慮し、可能な限り新しい鍵に切り替える計画を立てる
  • 移行時にデータの再暗号化(リキーイング)を行うことで、セキュリティを強化できます

アルゴリズム非推奨時の対応

暗号アルゴリズムは時代とともに安全性が変化し、非推奨(Deprecated)となることがあります。

非推奨アルゴリズムを使い続けることはセキュリティリスクを高めるため、適切な対応が必要です。

• 非推奨アルゴリズムの例
  • DESや3DESは既に脆弱性が指摘されており、多くの環境で非推奨
  • SHA-1は衝突攻撃のリスクが高く、署名やハッシュ用途での使用が避けられています
  • RSAの鍵長1024ビット以下は安全性が低いとされています
• 対応策
  • 新しい安全なアルゴリズムやパラメータ(AES-256、SHA-256以上、RSA 2048ビット以上)に移行します
  • 移行計画を立て、段階的に非推奨アルゴリズムの使用を停止します
  • 既存データの再暗号化や署名の再生成を検討します
• C#での実装変更例
  • SHA1からSHA256へのハッシュアルゴリズム切り替え
  • RSAEncryptionPadding.Pkcs1からRSAEncryptionPadding.OaepSHA256へのパディング方式変更
  • AesCryptoServiceProviderからAes.Create()を使い、最新の暗号モードを利用
• 運用上の注意
  • 非推奨アルゴリズムを使っている箇所をコードレビューや静的解析ツールで検出します
  • ベンダーやコミュニティのセキュリティアドバイザリを定期的に確認し、最新情報を反映します
  • 移行に伴う互換性問題を事前に検証し、影響範囲を把握します

これらのポイントを踏まえ、バージョン間の互換性を保ちつつ、安全で最新の暗号技術を活用する移行戦略を策定してください。

法的・コンプライアンス視点

暗号輸出規制の概要

暗号技術は国家安全保障や国際関係に影響を与えるため、多くの国で輸出規制の対象となっています。

日本を含む多くの国では、暗号製品や技術の輸出に関して法律や規制が設けられており、これに違反すると罰則が科されることがあります。

• 日本の暗号輸出規制

日本では「外国為替及び外国貿易法(外為法)」に基づき、暗号技術の輸出が管理されています。

特に強力な暗号技術や軍事転用可能な技術は、経済産業省の許可が必要です。

• 規制対象
  • ソフトウェアやハードウェアに組み込まれた暗号機能
  • 暗号アルゴリズムのソースコードや設計情報
  • 暗号鍵や関連技術の輸出
• 輸出許可の申請
  • 輸出先の国や用途によって許可が必要か判断されます
  • 一般的な商用暗号製品は緩和措置がある場合もあるが、事前確認が必須
  • 違反した場合は罰金や刑事罰の対象となります
• 国際的な規制
  • 米国のEAR(Export Administration Regulations)やWassenaar Arrangementなど、多国間で暗号輸出規制が調整されています
  • クロスボーダーでのソフトウェア配布やクラウドサービス提供時は、各国の規制を確認する必要があります

個人情報保護法と暗号化義務

日本の個人情報保護法(PPC法)は、個人情報の適切な取り扱いを義務付けており、特に個人情報の漏洩防止策として暗号化の実施が推奨されています。

• 暗号化の位置づけ
  • 個人情報の安全管理措置の一環として、技術的な対策に暗号化が含まれます
  • 重要な個人情報を保存・送信する際は、漏洩リスクを低減するために暗号化を行うことが望ましい
• 具体的な要件
  • 保存時の暗号化(ファイルやデータベースの暗号化)
  • 通信時の暗号化(TLSなどの安全な通信プロトコルの利用)
  • キー管理の適切な実施
• 違反時のリスク
  • 個人情報漏洩が発覚した場合、行政指導や罰則の対象となります
  • 企業の信用失墜や損害賠償請求のリスクも高まります
• ガイドラインの活用
  • 個人情報保護委員会が公開する「個人情報の安全管理に関するガイドライン」などを参考に、暗号化の実装や運用を検討します

監査対応ドキュメント整備

暗号化システムの運用においては、法令遵守や内部統制の観点から監査対応が求められます。

適切なドキュメントを整備し、監査時に迅速かつ正確に対応できる体制を構築することが重要です。

• 必要なドキュメント例
  • 暗号化アルゴリズムやキー管理ポリシーの仕様書
  • キー生成・配布・廃棄の手順書
  • ログ管理やアクセス制御の運用ルール
  • セキュリティインシデント対応手順
  • 定期的なリスク評価や脆弱性診断の報告書
• ドキュメントのポイント
  • 最新の状態を維持し、変更履歴を明確に管理します
  • 関係者が理解しやすい形式で作成し、教育や訓練に活用します
  • 監査で求められる証跡(証明書、ログ、承認記録など)を確実に保存します
• 監査対応の実践
  • 内部監査や外部監査に備え、定期的にドキュメントのレビューと更新を行います
  • 監査指摘事項に対しては迅速に改善策を実施し、報告します
  • 監査結果を経営層に報告し、セキュリティ体制の強化を図ります

これらの法的・コンプライアンス要件を踏まえ、C#での暗号化実装や運用を適切に設計・管理することが求められます。

まとめ

この記事では、C#を用いたAESとRSAによる暗号化・復号化の基本から、安全なキー管理、ハイブリッド暗号化モデル、追加のセキュリティ強化策、運用上の注意点まで幅広く解説しました。

暗号技術の基礎や実装ポイント、パフォーマンス最適化、法的・コンプライアンス面の考慮も含め、実践的かつ安全な暗号化システム構築に必要な知識が得られます。

これにより、堅牢で効率的なC#アプリケーションの暗号化設計が可能になります。