設定
迅速な配送
送料は無料
Incoterms
お支払い方法
マーケットプレイス製品
IoTセキュリティの基礎（第1部）：暗号の使用
DigiKeyの北米担当編集者の提供
2020-06-03
編集者注：5回に分けてお届けするこのシリーズでは、開発者が最初からベストプラクティスを実践するのに役立つ実際的なガイダンスを提供します。この第1部では、安全設計の基盤となる暗号アルゴリズムについて説明します。第2部では、セキュアシステム内での秘密鍵の役割、鍵管理、およびセキュアストレージについて説明します。第3部では、IoTデバイス上でシステムおよびアプリケーションソフトウェアの実行を妨害するために仕組まれた脅威を低減するために、セキュアプロセッサに組み込まれたメカニズムについて説明します。第4部では、高度なプロセッサでセキュリティメカニズムを適用して、IoTデバイスのランタイム環境に対する攻撃を低減するのに必要な隔離を確保する方法を特定して紹介します。第5部では、IoTデバイスから、これらのデバイスをIoTクラウドリソースに接続するために使用されるハイレベルのセキュリティ対策へとIoTセキュリティを移行する方法について説明します。
産業用、医療用、輸送用、および他の重要なアプリケーションでは、IoTアプリケーションへの依存度が急速に高まっていますが、このことによってセキュリティの情勢が劇的に変化しました。以前のエンタープライズアプリケーションでは、セキュリティアルゴリズムを処理するためのリソースの入手が簡単でした。増大する一連の脅威は、リソース制約のあるIoTデバイスのネットワークを標的としており、容易なリソース入手便を持たないエンタープライズレベルのIoTアプリケーションは、これらの脅威に対して脆弱です。急速に出現したIoTのチャンスに対応しようと急ぐ多くの企業は、保存されたデータを保護したり、脆弱なネットワーク全体でのデータとコマンドの交換を保護するための基本的セキュリティ対策をサポートできないまま、IoTデバイスを展開していることがよくあります。
もちろん、設計を保護するために開発者がどこまで行う必要があるかは、複数の要因に依存します。各アプリケーションは独自の脅威に直面しており、それらの脅威によるリスクに対する適切な評価を必要としています。コネクテッドデバイスは尋常でない数の脅威に直面しているため、どんなIoTデバイスにも最低限のセキュリティ対策が必要です。
シンプルなIoTデバイスに堅牢なセキュリティ対策を実装することはオーバースペックのようにも思えるかもしれませんが、シンプルな温度センサデバイスでさえ、十分な保護がないとハッカーに企業ネットワークへのエントリポイントを提供してしまう可能性があります[1]。確かに、IoTアプリケーションが提供する広範なコネクティビティとこれらのアプリケーションを基盤とするリソースの限られたデバイスの組み合わせにより、IoTセキュリティは絶えず課題に直面しています。実際、ソフトウェアで暗号アルゴリズムを実行するための十分なリソースを備えたIoTデバイス設計でさえも、それらのアルゴリズムを実装する際のわずかなエラーによって、アプリケーションが攻撃を受けやすいままにしてしまうことがあります。
この記事では、暗号アルゴリズムの基本的クラスとセキュリティにおけるその役割について説明します。次に、これらのアルゴリズムを加速化し、実装を簡素化しつつセキュリティのさまざまな要素を強化するために設計された、Maxim Integrated、Microchip Technology、およびTexas Instrumentsのプロセッサおよび特殊デバイスを開発者が活用できる方法を示します。
さまざまなタイプの暗号アルゴリズムとその役割
暗号アルゴリズムは、機密性、認証（メッセージの送信元の確認）、否認防止（送信者が暗号化または署名されたメッセージを作成したことの証明）、および完全性という基本的なセキュリティ原則に対処する以下3つの大きなカテゴリに分類されます。
- 対称鍵アルゴリズム。このアルゴリズムまたは暗号は、同じ秘密鍵を使用して、人間が読める（平文）メッセージを保護されたバージョン（暗号文）へと暗号化し、後にその暗号文を平文へ復号します。対称鍵暗号は、一般的に機密性を確保するために使用されます。一般的な対称暗号アルゴリズムには、以下が含まれます。
- 3DESとも呼ばれるトリプルDES（データ暗号化標準）、またはアメリカ国立標準技術研究所（NIST）による正式名称Triple Data Encryption Algorithm（TDEA）。
- 高度暗号化標準（AES）[2]アルゴリズム（256ビットの鍵を使用するAES-256など）。
- 非対称鍵アルゴリズム。一般的には鍵の交換およびデジタル署名用のより広範なセキュリティプロトコルの一部として、暗号に秘密鍵と公開鍵の組み合わせを使用し、メッセージを暗号化および復号化します。非対称暗号は、一般的に機密性、認証、または否認防止を確保するために使用されます。公開鍵暗号アルゴリズムには、以下が含まれます。
- 以下を含む有限体暗号（FFC）を使用するアルゴリズム：
- 連邦情報処理標準（FIPS）デジタル署名アルゴリズム （DSA）
- インターネット技術特別調査委員会（IETF）ディフィーヘルマン（DH）[3]鍵交換
- 以下を含む、整数因数分解暗号（IFC）を使用するアルゴリズム：
- RSA（Rivest–Shamir–Adleman）[4]アルゴリズム
- 以下を含む、楕円曲線暗号（ECC）を使用するアルゴリズム：
- 楕円曲線ディフィーヘルマン（ECDH）[5]鍵交換
- 楕円曲線デジタル署名アルゴリズム（ECDSA）[6]
- 以下を含む有限体暗号（FFC）を使用するアルゴリズム：
- ハッシュアルゴリズム。このアルゴリズムは、オリジナルメッセージをハッシュ、ダイジェスト、署名などさまざまに呼ばれるずっと小さな独自の固定長値に減らします。これらの一方向の変換関数は、メッセージが変更されていないこと（完全性）を確認するうえで重要な役割を果たし、メッセージ認証コード（MAC）、鍵付きハッシュメッセージ認証コード（HMAC）、または鍵導出関数（KDF）などが関係する複数のプロトコルに応用されます。暗号ハッシュアルゴリズムには、以下が含まれます。
- MD5（メッセージダイジェスト5）
- セキュアハッシュアルゴリズム（SHA）[7]（メッセージに対して256ビットのハッシュ値を生成するSHA-256など）。
上記のアルゴリズムは他の効果的な暗号アルゴリズムと同様に、この短い記事の範囲をはるかに超越した複数の重要な要件に基づいて設計されています。ただし、幅広い観点から、鍵ベースのアルゴリズムは、鍵なしで復号することが事実上不可能（または少なくとも経済的に実現不可能）な暗号文を生成する必要があります。ハッシュアルゴリズムとしては、ハッシュを迅速に生成する必要があり、同じ入力メッセージに対して同じハッシュを生成しますが、入力メッセージのわずかな変化に対しても著しく異なるハッシュを生成します。ただし、2つの異なるメッセージに同じハッシュ値を生成したり、特定のハッシュ値に対して元のメッセージを生成したりすることは決してありません。
これらや他の暗号アルゴリズムの詳細は大幅に異なりますが、すべてはこれらの全体目標を達成するために設計された一連の低レベルの操作、変換、および他の数学演算に依存しています。たとえば、AES暗号は、ユーザーの元の秘密鍵から得られる独自の「ラウンド鍵」を組み込んだ一連の「ラウンド」を使用して、平文を暗号文に変換します（リスト1）。
コピー
Cipher(byte in[4*Nb], byte out[4*Nb], word w[Nb*(Nr+1)])
begin
byte state[4,Nb]
state = in
AddRoundKey(state, w[0, Nb-1])
for round = 1 step 1 to Nr–1
SubBytes(state)
ShiftRows(state)
MixColumns(state)
AddRoundKey(state, w[round*Nb, (round+1)*Nb-1])
end for
SubBytes(state)
ShiftRows(state)
AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1])
out = state
end
リスト1：この疑似コードはメッセージ暗号化に関連した演算のシーケンスを表しており、送信者の秘密鍵から得られる一連の値（w）を使用して、平文（in）を暗号文（out）に変換します。（コード提供：NIST）
ラウンド内で、SubBytes()変換は、それ自体も一連の変換の結果である変換テーブル（S-box）を使用して、各バイトを置き換えます（図1）。
図1：AES暗号では、SubBytes()ステージが変換テーブル（S-box）を使用して各バイトを置き換えます。（画像提供：NIST）
シーケンスの次のステップでは、ShiftRows()変換が最後の3つの行のバイトを、行ごとに異なるバイト数だけ移動させます（図2）。
図2：AES暗号実行シーケンスのShiftRows()ステージは、オフセットを増やすことにより行を移動させます。（画像提供：NIST）
シーケンスの最終ステップでは、MixColumns()が各列に変換を適用し、列内の各バイトを多項式の結果で置き換えます。一方、AddRoundKey()は、その目的のために作成されたラウンド鍵を使用して、各列でビット単位のXOR演算を実行することにより、結果を変換します。
ラウンドの総数は、鍵のサイズによって変わります。128ビット鍵を使用するAES-128には10ラウンドが必要ですが、AES-192（鍵サイズ192ビット）とAES-256（256ビット）にはそれぞれ12および14ラウンドが必要です。復号も同じパターンに従い、プロセスステップと個別の変換を反転させます。
鍵交換に使用されるECDHやデジタル署名に使用されるECDSAのような最新の暗号は、数式によって広く定義される楕円曲線の代数構造などのより複雑な計算に依存しています。
式1
曲線パラメータaおよびbの注意深い選択と追加制約の使用により、曲線は有用な暗号プロパティを提供します（この記事の範囲外）。概念的にはシンプルですが、具体的なパラメータのセットが重要です。曲線パラメータの選択を間違えると、曲線が高度な攻撃に対して脆弱なままになる場合があります。この可能性を排除するために、NISTはP-192、P-224、P-256、および他の強力な曲線を含む暗号的に堅牢な曲線の標準セットを提供しています。曲線の名前は、曲線の基盤となる素体にある要素の素数pのビット長に対応しています。
開発者はECDSAでこれらのプロパティを使用し、合意済みの曲線を使用して一部のメッセージに署名し、公開鍵と署名（rおよびsとラベル付けされた1組の数字）を受領者に提供できます。実際の署名プロセスには、以下の手順が関係します。
- 基点G(x,y)と呼ばれる曲線のある地点から始めて、アルゴリズムはpを法として開発者の秘密鍵（d）で基点を増加させることにより、公開鍵Q(x,y)を作成します。
式2
- [1 ... n-1]の範囲で乱数kを使用して、別の座標点（x1、y1）が作成されます。
式3
- メッセージmのSHAハッシュであるH(m)が生成されます。
- 乱数k、k-1のモジュラ逆数を使用して、デジタル署名の最後のrおよびsコンポーネントは以下のように生成されます。
式4
式5
最終的な結果は、メッセージを認証し、完全性を確認し、否認防止を確保する交換です。
暗号アルゴリズムの実装方法
これらのアルゴリズムに対するこの明らかに表面的な見方の実例は、結果に不正アクセスする試みの計算コストが高すぎて、犯罪者に役立つほど迅速に完了することが不可能（または非現実的）になるように設計された数学演算のシーケンスに暗号アルゴリズムが依存することです。加えて、各アルゴリズムの大まかな調査でさえ、リソースに制約のあるIoTデバイスには、デバイスの主要な機能要件を妥協することなくアルゴリズムのソフトウェア実装を実行する可能性がほとんどないことを示しています。最後に、ここで示した手順以外のアルゴリズムの正確な詳細によると、わずかなコーディングエラーまたはささいな基準の誤解が、セキュリティの脆弱性、さらには暗号プロセスの完全な失敗につながります。
アルゴリズムの実装におけるエラーは、最大規模の開発組織やこれらのアルゴリズムに大いに依存するアプリケーションでも発生する可能性があります。たとえば、よく知られたゲーム機の脆弱性は、企業によるECDSAの実装が、式3に示すような計算で、乱数値ではなくkの一定値を使用したために発生しました。結果として、ハッカーは秘密鍵dを入手することができました。kを作成するために欠陥のある乱数発生器を使用したことにより、同様の攻撃が発生し、ビットコインの大損失につながりました。
プロセッサに組み込まれたハードウェアベースの暗号機能と専用セキュリティICにより、開発者は暗号アルゴリズム実行の複雑な詳細をほとんど無視する代わりに、それらの機能を使用してアプリケーションを保護する利点に集中することができます。これらのデバイスは、データフローや演算をデバイス内に組み込み、内部情報の兆候を求めて外部バスを監視する一般的な攻撃形態を排除することにより、セキュリティをさらに向上させます。特定のアルゴリズムの信頼できる実装を提供することに加えて、ハードウェアベースのソリューションにより、応答レイテンシや全体的な性能などの基本的要件を妥協することなく、開発者はセキュリティを設計に組み込むことができます。
これらのデバイスに組み込まれた暗号アクセラレータは、メインプロセッサから暗号実行をオフロードし、設計の主要機能を処理するためにそれを解放します。実際、ハードウェアベースの暗号サポートは、プロセッサにとってますます一般的な機能となっています。その一方で、すべてのアプリケーションが上記のアルゴリズムによりサポートされるセキュリティ対策全体を必要とするわけではありません。実際に、開発者は以下のようなプロセッサで幅広い加速暗号アルゴリズムやアルゴリズムの組み合わせを見つけることができます。
- Maxim IntegratedのMAX32631 32ビットマイクロコントローラ（AESおよびDSA暗号をサポート）
- Maxim IntegratedのMAX32520 32ビットMCU（AES/SHA/ECDSAアルゴリズムをサポート）
- Microchip TechnologyのPIC 24F XLP 16ビットマイクロコントローラファミリの製品（AESおよび3DES暗号をサポートするPIC24FJ256GA406などのデバイス）
- Microchip Technologyの32ビットPIC 32MZ MCUおよび32ビットSAM9X60 MPUファミリの製品（AES/3DES暗号およびSHA/HMACハッシュ関数をサポートするPIC32MZ2048EFM144およびSAM9X60Tなどのデバイス）
- Texas InstrumentsのSimpleLink MCUファミリの製品（AES/ECDH/ECDSA暗号やSHAハッシュ関数をサポートするCC1312RおよびCC2652RワイヤレスMCUなど）
Maxim IntegratedのDS28E38およびMicrochip TechnologyのATECC608Aなど、他のセキュリティデバイスは、認証プロトコルを高速化するのに必要な暗号アクセラレータと関連機能を統合しています。広範な暗号機能の1つとして、これらのデバイスは前述したようなECDSA演算をサポートします。IoTデバイスまたはスマート周辺機器において、ホストプロセッサはこれらのような認証ICを使用し、ECDSA P-256デジタル署名を迅速に作成して別のデバイスに送信したり、他のデバイスからECDSA P-256署名を認証したりできます。
一般的に、セキュリティ対応のプロセッサおよび特殊デバイスは、高品質な乱数発生器などの追加セキュリティ機能を提供する広範なハードウェアベースのセキュリティフレームワークで構築されています。このレベルの機能を提供する多くのデバイスは、半導体設計固有のランダムノイズ源を活用して、真性乱数発生器（TRNG）に必要なエントロピを最大化します。前述のビットコインの例が示すように、この種のTRNGは、暗号アルゴリズムの適切な演算において不可欠な要素です。
秘密鍵や他の機密データのセキュアストレージに対する組み込みサポートにより、セキュア設計の最も重要な機能の1つが提供されます。これらおよび類似のプロセッサで利用可能な他のアーキテクチャ機能により、さらに深いレベルのセキュリティサポートが提供されます。
すべての機能において、暗号アクセラレータおよび関連機能を備えたプロセッサは、簡単なアプリケーションプログラミングインターフェース（API）ライブラリの使用により、セキュア設計の開発を簡素化するのに役立ちます。直観的なAPI関数呼び出しにより、開発者はセキュリティ実装を抽象化し、APIに依存して基盤となるハードウェア機能にアクセスできます。たとえば、開発者はMaxim IntegratedのMAX32520 MCU用MAX32520-KIT評価キットをMaxim IntegratedのMicrosソフトウェア開発キット（SDK）と組み合わせて使用し、セキュアなIoTデバイスを迅速に構築できます。関連ドライバおよびミドルウェアに加えて、Maxim IntegratedのMicros SDKには、AES暗号を使用してメッセージを暗号化（AES128_ECB_enc()）および復号化（AES128_ECB_dec ()）するのに必要な基本設計パターンを示すサンプル関数が含まれます（リスト2）。
コピー
int AES128_ECB_enc(int asynchronous)
{
printf( asynchronous ? "Test Cipher Async\n" : "Test Cipher Sync\n");
char *_key = "797f8b3d176dac5b7e34a2d539c4ef36";
char key[MXC_AES_KEY_128_LEN];
ascii_to_byte(_key, key, MXC_AES_KEY_128_LEN);
const char *iv_src = "";
char iv_dst[16];
ascii_to_byte(iv_src, iv_dst, 16);
char *_pt= "00000000000000000000000000000000";
char pt[MXC_AES_DATA_LEN];
ascii_to_byte(_pt, pt, MXC_AES_DATA_LEN);
mxc_ctb_cipher_req_t cipher_req = {
(uint8_t*)pt,
MXC_AES_DATA_LEN,
(uint8_t*)iv_src,
(uint8_t*)result,
&Test_Callback };
// Reset crypto block
MXC_CTB_Init(MXC_CTB_FEATURE_CIPHER | MXC_CTB_FEATURE_DMA);
MXC_CTB_IntEnable(asynchronous);
MXC_CTB_Cipher_SetMode(MXC_CTB_MODE_ECB);
MXC_CTB_Cipher_SetCipher(MXC_CTB_CIPHER_AES128);
MXC_CTB_Cipher_SetKeySource(MXC_CTB_CIPHER_KEY_SOFTWARE);
// Load key into cipher key register
MXC_CTB_Cipher_SetKey((uint8_t *)key, MXC_AES_KEY_128_LEN);
if (asynchronous){
wait = 1;
MXC_CTB_Cipher_EncryptAsync(&cipher_req);
while( wait );
} else {
MXC_CTB_Cipher_Encrypt(&cipher_req);
}
const char *_expected = "322FD6E503395CDB89A77AC53D2B954F";
char expected[MXC_AES_DATA_LEN];
ascii_to_byte(_expected, expected, MXC_AES_DATA_LEN);
return AES_check(result, expected, MXC_AES_DATA_LEN);
}
int AES128_ECB_dec(int asynchronous)
{
printf( asynchronous ? "Test Cipher Async\n" : "Test Cipher Sync\n");
char *_key = "797f8b3d176dac5b7e34a2d539c4ef36";
char key[MXC_AES_KEY_128_LEN];
ascii_to_byte(_key, key, MXC_AES_KEY_128_LEN);
const char *iv_src = "";
char iv_dst[16];
ascii_to_byte(iv_src, iv_dst, 16);
char *_pt= "322FD6E503395CDB89A77AC53D2B954F";
char pt[MXC_AES_DATA_LEN];
ascii_to_byte(_pt, pt, MXC_AES_DATA_LEN);
mxc_ctb_cipher_req_t cipher_req = {
(uint8_t*)pt,
MXC_AES_DATA_LEN,
(uint8_t*)iv_src,
(uint8_t*)result,
&Test_Callback };
// Reset crypto block
MXC_CTB_Init(MXC_CTB_FEATURE_CIPHER | MXC_CTB_FEATURE_DMA);
MXC_CTB_IntEnable(asynchronous);
MXC_CTB_Cipher_SetMode(MXC_CTB_MODE_ECB);
MXC_CTB_Cipher_SetCipher(MXC_CTB_CIPHER_AES128);
MXC_CTB_Cipher_SetKeySource(MXC_CTB_CIPHER_KEY_SOFTWARE);
// Load key into cipher key register
MXC_CTB_Cipher_SetKey((uint8_t *)key, MXC_AES_KEY_128_LEN);
if (asynchronous){
wait = 1;
MXC_CTB_Cipher_DecryptAsync(&cipher_req);
while( wait );
} else {
MXC_CTB_Cipher_Decrypt(&cipher_req);
}
const char *_expected = "00000000000000000000000000000000";
char expected[MXC_AES_DATA_LEN];
ascii_to_byte(_expected, expected, MXC_AES_DATA_LEN);
return AES_check(result, expected, MXC_AES_DATA_LEN);
}
リスト2：開発者は、Maxim IntegratedのMicros SDKディストリビューションパッケージのサンプルコードを調べることにより、MAX32520 MCUの組み込み暗号関数を使用してAES暗号化（AES128_ECB_enc()）および復号化（AES128_ECB_dec ()）を実行するのに必要な基本設計パターンを学ぶことができます。（コード提供：Maxim Integrated）
認証プロトコル
堅牢な暗号アルゴリズムの実装は、アプリケーションで使用されるより高いレベルのプロトコルのセキュアな基盤を提供するために特に重要です。一般的に、トランスポートレイヤセキュリティ（TLS）などの高レベルなプロトコルは、暗号スイートと呼ばれる暗号アルゴリズムの定義済みセットを使用して演算を実行します。TLSでは、合意済みの暗号スイートから引き出されたアルゴリズムは、IoTデバイスクライアントとホストサーバ間の通信セッションにおいて認証と機能性を確保するのに役立ちます。TLS 1.2[8]は、トランザクションの特定シーケンスを経て、パラメータをネゴシエートし、認証を実行し、セッションキーを交換してからデータ交換に進みます（図3）。
図3：TLS 1.2セッション作成プロトコルは、認証、鍵交換、および進行中のデータ交換用に、合意済みの暗号スイートからさまざまなアルゴリズムを使用します。（画像提供：Texas Instruments）
認証は、各参加者の公開鍵を含むセキュリティ証明書の検証により、サーバ（およびオプションでクライアント）のIDを確立することで保証されます。ここで、各参加者は秘密鍵で暗号化されたメッセージを送信します。受信した公開鍵は関連付けられた秘密鍵で暗号化されたメッセージのみを復号できるため、各参加者は証明書の提供者がその証明書を実際に所有していることを確認できます。
次のTLS段階では、参加者は一連のトランザクションを実行して、共有セッションキーを作成します。それから、この共有セッションキーは、実際のメッセージトラフィックを暗号化するために使用されます。これにより、そのセッションのメッセージ交換の機密性が確保されます。
複数のプロトコルオプションにより、開発者はこの一般的なTLSセッション作成プロセスを改良できます。これは、全体的なセキュリティにとってマイナスになる場合もあります。加えて、開発者はパラメータ交換プロセス中に、プロトコルの各フェーズに対して以下のTLS 1.2対応アルゴリズムの適切な組み合わせを選択することにより、異なる暗号スイートを使用できます。
- 鍵の確立：RSA、DH、ECDH
- 認証：RSA、DSA、ECDSA
- 暗号：3DES、AES
- メッセージ認証： SHA
TLSの最新バージョンであるTLS 1.3[9]は、最初に鍵交換を実行してセッション作成プロセスをより良く保護することにより、さらにセキュリティを向上させます。より根本的に、TLS 1.3はTLS 1.2暗号スイートの大部分を廃止して、HMACベースの"抽出して展開"鍵導出関数（HKDF）の使用を含むより堅牢なアルゴリズム、および認証付き暗号（AEAD）アルゴリズムを採用しています。AEADアルゴリズムは、メッセージの信頼性、完全性、および機密性を確保するための幅広いニーズに対処します。これらのアルゴリズムは、暗号化されたメッセージを直列（図4左）、並列（図4右）、またはその両方の組み合わせで生成可能なMACと組み合わせることによってそれを実現します。
図4：AEADは、他の手法に加えて、MACを直列または並列で計算するencrypt-then-MAC（左）およびencrypt-and-MAC（右）と呼ばれる方法を使用してMACを暗号文に含めることにより、認証と機密性を提供します。（画像提供：Wikipedia）
セキュリティ強度の向上
この暗号アルゴリズムおよび関連プロトコルの進化は、セキュリティの強化を決意している暗号専門家とそのセキュリティの突破を同様に決意している人々の間の継続的な競争につながります。たとえば、セキュリティを強化するために、専門家はDSA（それ自体も旧世代の暗号のバリアント）のECCバリアントとしてECDSAを作成しました。その結果、ECDSAは、はるかに小さな鍵サイズでDSAと同じセキュリティ強度を実現できました。
暗号において、アルゴリズムのセキュリティ強度は、xビット、および攻撃がアルゴリズムの基盤となる秘密鍵を取得するのに約2xの演算が必要になるとの見込みにより定義されています。これらの条件で定義されたさまざまなクラスのアルゴリズムは、同等のセキュリティレベルを実現するために大きく異なる鍵の長さを必要とする可能性があります（表1）。
表1：さまざまなクラスの暗号アルゴリズムは、同等のセキュリティ強度を実現するために、大きく異なる鍵サイズの公開鍵（L）または秘密鍵（N、k、f）を必要とする可能性があります。（画像提供：NIST）
NISTが提供するこの表では、FFCアルゴリズムのパラメータLおよびNは、それぞれ公開鍵および秘密鍵のサイズに対応します。IFCおよびECCアルゴリズムでは、kおよびfは、それぞれの鍵のサイズに対応します。NISTは、セキュリティ強度80以下（表ではオレンジ色の背景）のアルゴリズムが政府情報保護には承認されなくなったことに言及していますが、その他のアルゴリズム（黄色の背景）は効率性の懸念事項が原因でNIST標準にまだ含まれていません。
このセキュリティ強度向上への動きは、暗号や推奨される暗号スイートの進化を推進し続けます。たとえば、アメリカ国家安全保障局（NSA）の商用国家セキュリティアルゴリズム（CNSA）スイートは、最高機密として分類された情報を保護するのに必要なより堅牢なパラメータの使用に関する推奨事項によって、以前のNSAスイートBを置き換えました。
表2：NSAが推奨するCNSAスイートには、高度に機密性の高い情報を保護するのに必要な最低レベルのセキュリティ強度の推奨事項を備えた暗号アルゴリズムが含まれます。（画像提供：Digi-Key、NSAデータより）
今後の展望としては、量子計算能力の可用性により、一般的なセキュリティ、特に暗号アルゴリズムにおいて、劇的な不連続性がもたらされるでしょう。
結論
IoTデバイスや他のコネクテッド設計は脅威の増大に直面しており、幅広い暗号アルゴリズムに基づくいっそう堅牢なセキュリティ手段を必要としています。これらのアルゴリズムは、セキュリティへの攻撃を無力化するために設計されており、平文を暗号文に暗号化したり、暗号文を平文に復号するための一連の変換と数学演算に依存しています。前述のとおり、これらのアルゴリズムをハードウェアベースで実装することで、機能や性能の基本的要件を損なうことなく、開発者がより簡単に強力なセキュリティを設計に組み込めるようになります。
参照資料：
免責条項：このウェブサイト上で、さまざまな著者および/またはフォーラム参加者によって表明された意見、信念や視点は、DigiKeyの意見、信念および視点またはDigiKeyの公式な方針を必ずしも反映するものではありません。
日本