次の方法で共有

.NET Core 2.1-3.0 の暗号化の破壊的変更

このページでは、次の破壊的変更について説明します。

重大な変更 導入されたバージョン
Linux で BEGIN TRUSTED CERTIFICATE 構文がサポートされなくなった 3.0
EnvelopedCms で AES-256 暗号化を既定で使用 3.0
RSAOpenSsl キー生成の最小サイズの増加 3.0
.NET Core 3.0 では、OpenSSL 1.0.x よりも OpenSSL 1.1.x を優先する 3.0
CryptoStream.Dispose は書き込み時にのみ最後のブロックを変換する 3.0
SignedCms.ComputeSignature のブール値パラメーターが優先されます 2.1

.NET Core 3.0

Linux のルート証明書に対して "BEGIN TRUSTED CERTIFICATE" 構文がサポートされなくなった

Linux およびその他の Unix 類似システム (macOS 以外) のルート証明書は、標準の BEGIN CERTIFICATE PEM ヘッダーと、OpenSSL 固有の BEGIN TRUSTED CERTIFICATE PEM ヘッダーの 2 つの形式で提示できます。 後者の構文では、.NET Core の System.Security.Cryptography.X509Certificates.X509Chain クラスとの互換性の問題の原因となる追加の構成が可能です。 BEGIN TRUSTED CERTIFICATE ルート証明書の内容は、.NET Core 3.0 以降のチェーン エンジンでは読み込まれなくなりました。

変更の説明

以前は、ルート信頼リストを設定するために、BEGIN CERTIFICATE と BEGIN TRUSTED CERTIFICATE 両方の構文が使用されていました。 BEGIN TRUSTED CERTIFICATE 構文を使用し、ファイルで追加のオプションを指定した場合、信頼チェーンが明示的に禁止されたことが、X509Chain によって報告される場合があります (X509ChainStatusFlags.ExplicitDistrust)。 ただし、その証明書が、それより前に読み込まれたファイルの BEGIN CERTIFICATE 構文でも指定されていた場合は、信頼チェーンは許可されました。

.NET Core 3.0 以降、BEGIN TRUSTED CERTIFICATE の内容は読み取られなくなりました。 証明書が標準の BEGIN CERTIFICATE 構文でも指定されていない場合、X509Chain ではルートが信頼されていないと報告されます (X509ChainStatusFlags.UntrustedRoot)。

導入されたバージョン

3.0

ほとんどのアプリケーションはこの変更の影響を受けませんが、アクセス許可の問題のために両方のルート証明書ソースを確認できないアプリケーションでは、アップグレード後に予期しない UntrustedRoot エラーが発生する可能性があります。

多くの Linux ディストリビューションでは、ルート証明書はファイルごとに 1 証明書のディレクトリと、1 ファイル連結の 2 つの場所に書き込まれます。 一部のディストリビューションでは、ファイルごとに 1 証明書のディレクトリには BEGIN TRUSTED CERTIFICATE 構文が使用され、ファイル連結には標準の BEGIN CERTIFICATE 構文が使用されています。 これらの場所の少なくとも 1 つにすべてのカスタム ルート証明書が BEGIN CERTIFICATE として追加されていること、およびアプリケーションで両方の場所を読み取ることができることを確認してください。

一般的なディレクトリは /etc/ssl/certs/ であり、一般的な連結されたファイルは /etc/ssl/cert.pem です。 プラットフォーム固有のルートを確認するには、openssl version -d コマンドを使用します。これは、 /etc/ssl/ と異なる場合があります。 たとえば、Ubuntu 18.04 では、ディレクトリは /usr/lib/ssl/certs/ であり、ファイルは /usr/lib/ssl/cert.pem です。 ただし、 /usr/lib/ssl/certs/ は /etc/ssl/certs/ へのシンボリック リンクであり、 /usr/lib/ssl/cert.pem は存在しません。

$ openssl version -d
OPENSSLDIR: "/usr/lib/ssl"
$ ls -al /usr/lib/ssl
total 12
drwxr-xr-x  3 root root 4096 Dec 12 17:10 .
drwxr-xr-x 73 root root 4096 Feb 20 15:18 ..
lrwxrwxrwx  1 root root   14 Mar 27  2018 certs -> /etc/ssl/certs
drwxr-xr-x  2 root root 4096 Dec 12 17:10 misc
lrwxrwxrwx  1 root root   20 Nov 12 16:58 openssl.cnf -> /etc/ssl/openssl.cnf
lrwxrwxrwx  1 root root   16 Mar 27  2018 private -> /etc/ssl/private

カテゴリ

暗号

影響を受ける API

EnvelopedCms が AES-256 暗号化を既定で使用

EnvelopedCms で使用される既定の対称暗号化アルゴリズムが TripleDES から AES-256 に変更されました。

変更の説明

以前のバージョンでは、コンストラクターのオーバーロードを使って対称暗号化アルゴリズムを指定せずに EnvelopedCms を使用してデータを暗号化する場合、データは TripleDES/3DES/3DEA/DES3-EDE アルゴリズムで暗号化されます。

.NET Core 3.0 以降では (System.Security.Cryptography.Pkcs NuGet パッケージのバージョン 4.6.0 を介して)、アルゴリズムを最新化し、既定のオプションのセキュリティを向上するために、既定のアルゴリズムが AES-256 に変更されました。 メッセージ受信者の証明書に Diffie-Hellman (非 EC) 公開キーが含まれている場合、基になるプラットフォームの制限のために、暗号化操作は、CryptographicException で失敗する可能性があります。

次のサンプル コードでは、.NET Core 2.2 以前で実行されている場合、データは TripleDES で暗号化されます。 NET Core 3.0 以降で実行されている場合は AES-256 で暗号化されます。

EnvelopedCms cms = new EnvelopedCms(content);
cms.Encrypt(recipient);
return cms.Encode();

導入されたバージョン

3.0

この変更によって悪影響を受ける場合は、型 EnvelopedCms を含む AlgorithmIdentifier コンストラクターで暗号化アルゴリズム識別子を明示的に指定することで、TripleDES 暗号化に戻すことができます。次に例を示します。

Oid tripleDesOid = new Oid("1.2.840.113549.3.7", null);
AlgorithmIdentifier tripleDesIdentifier = new AlgorithmIdentifier(tripleDesOid);
EnvelopedCms cms = new EnvelopedCms(content, tripleDesIdentifier);

cms.Encrypt(recipient);
return cms.Encode();

カテゴリ

暗号

影響を受ける API

RSAOpenSsl キー生成の最小サイズが増加しました

Linux で新しい RSA キーを生成する場合の最小サイズが、384 ビットから 512 ビットに増加しました。

変更の説明

.NET Core 3.0 以降では、Linux で LegalKeySizes、RSA.Create、および RSAOpenSsl から RSA インスタンス上の RSACryptoServiceProvider プロパティによって報告される最小の有効キー サイズが 384 から 512 に増えました。

その結果、.NET Core 2.2 以前のバージョンでは、RSA.Create(384) などのメソッドの呼び出しが成功しています。 .NET Core 3.0 以降のバージョンでは、メソッドの呼び出し RSA.Create(384) によって、サイズが小さすぎることを示す例外がスローされます。

この変更は、Linux で暗号化操作を実行する OpenSSL によって、バージョン 1.0.2 と 1.1.0 の間で最小値が増加したためです。 .NET Core 3.0 では、OpenSSL 1.0.x よりも 1.1.x が優先され、報告される最小バージョンが引き上げられ、この新しい依存関係のより高い制限が反映されます。

導入されたバージョン

3.0

影響を受ける API を呼び出す場合は、生成されるキーのサイズがプロバイダーの最小を下回らないようにしてください。

注

384 ビットの RSA は、既に安全ではないと見なされています (512 ビットの RSA も同様)。 NIST Special Publication 800-57 Part 1 Revision 4 などの最新の推奨設定では、新しく生成されるキーの最小サイズとして 2,048 ビットが提案されています。

カテゴリ

暗号

影響を受ける API

.NET Core 3.0 では、OpenSSL 1.0.x よりも OpenSSL 1.1.x が優先されます

Linux 用 .NET Core では、複数の Linux ディストリビューションで動作するため、OpenSSL 1.0.x と OpenSSL 1.1.x の両方がサポートされます。 .NET Core 2.1 および .NET Core 2.2 では、最初に 1.0.x が検索されてから、1.1.x にフォールバックされます。 .NET Core 3.0 では、最初に 1.1.x が検索されます。 この変更は、新しい暗号化標準のサポートを追加するために行われました。

この変更は、.NET Core で OpenSSL 固有の相互運用型とのプラットフォーム相互運用を行うライブラリまたはアプリケーションに影響を与える可能性があります。

変更の説明

.NET Core 2.2 以前のバージョンで、ランタイムでは OpenSSL 1.1.x よりも 1.0.x の読み込みが優先されます。 これは、OpenSSL との相互運用に使用する IntPtr と SafeHandle の型が優先設定に応じて libcrypto.so.1.0.0/libcrypto.so.1.0/libcrypto.so.10 のいずれかで使用されることを意味します。

.NET Core 3.0 以降で、ランタイムでは OpenSSL 1.0.x よりも OpenSSL 1.1.x の読み込みが優先されるため、OpenSSL との相互運用に使用する IntPtr と SafeHandle の型は優先設定に応じて libcrypto.so.1.1/libcrypto.so.11/libcrypto.so.1.1.0/libcrypto.so.1.1.1 のいずれかで使用されます。 その結果、OpenSSL と直接相互運用できるライブラリとアプリケーションは、.NET Core 2.1 または .NET Core 2.2 からアップグレードするときに、.NET Core で公開されている値と互換性のないポインターを持つ場合があります。

導入されたバージョン

3.0

OpenSSL を直接操作するライブラリやアプリケーションは、.NET Core ランタイムと同じバージョンの OpenSSL を使用するように注意する必要があります。

OpenSSL を直接使用する .NET Core 暗号化の種類から IntPtr または SafeHandle の値を使用するすべてのライブラリやアプリケーションでは、新しい SafeEvpPKeyHandle.OpenSslVersion プロパティで使用するライブラリのバージョンを比較し、ポインターの互換性を確保する必要があります。

カテゴリ

暗号

影響を受ける API

CryptoStream.Dispose は書き込み時にのみ最後のブロックを変換する

CryptoStream.Dispose 操作を完了するために使用される CryptoStream メソッドは、読み取り時に最後のブロックの変換を試行しなくなりました。

変更の説明

以前のバージョンの .NET では、ユーザーが CryptoStream モードで Read を使用するときに不完全な読み取りを実行した場合、Dispose メソッドから例外がスローされる可能性がありました (たとえば、パディングで AES を使用する場合)。 例外がスローされた理由は、最後のブロックの変換が試みられたがデータが不完全だったことにありました。

.NET Core 3.0 以降のバージョンでは、Dispose が読み取り時に最後のブロックの変換を試行しなくなりました。これにより、不完全な読み取りが許容されます。

変更の理由

この変更により、ネットワーク操作がキャンセルされたときに、例外をキャッチする必要なしに、暗号化ストリームからの不完全な読み取りが可能になります。

導入されたバージョン

3.0

ほとんどのアプリは、この変更の影響を受けることはありません。

不完全な読み取りが発生した場合にアプリケーションが例外をキャッチしても、その catch ブロックを削除できます。 ご利用のアプリがハッシュ シナリオで最後のブロックの変換を使用した場合、ストリーム全体が破棄される前にそれを確実に読み取るようにする必要がある可能性があります。

カテゴリ

暗号

影響を受ける API

.NET Core 2.1

SignedCms.ComputeSignature のブール値パラメーターが優先されます

.NET Core では、silent メソッドのブールSignedCms.ComputeSignature(CmsSigner, Boolean) パラメーターが考慮されます。 このパラメーターが true に設定されている場合、PIN プロンプトは表示されません。

変更の説明

.NET Framework では、silent メソッドのSignedCms.ComputeSignature(CmsSigner, Boolean) パラメーターは無視され、プロバイダーが必要とする場合は常に PIN プロンプトが表示されます。 .NET Core では、 silent パラメーターが優先され、 trueに設定されている場合、プロバイダーが必要とする場合でも PIN プロンプトは表示されません。

CMS/PKCS #7 メッセージのサポートは、バージョン 2.1 で .NET Core に導入されました。

導入されたバージョン

2.1

必要に応じて PIN プロンプトが表示されるようにするには、デスクトップ アプリケーションで SignedCms.ComputeSignature(CmsSigner, Boolean) を呼び出し、Boolean パラメーターを false に設定する必要があります。 結果の動作は、サイレント コンテキストが無効になっているかどうかに関係なく、.NET Framework の場合と同じです。

カテゴリ

暗号

影響を受ける API