私たちは、Jean-Phillip Omassonによる安全な暗号化プログラミングのための一連のルールの翻訳を続けています...

セキュリティ上重要なコードの一部に対するコンパイラの改ざんを防止

問題

一部のコンパイラは、役に立たないと考えられる操作を最適化します。

たとえば、コンパイラMS Visual C ++は演算子| memset |を見つけました。次のTor匿名ネットワーク実装コードのスニペット：

int crypto_pk_private_sign_digest(...) { char digest[DIGEST_LEN]; (...) memset(digest, 0, sizeof(digest)); return r; }

ただし、この演算子の役割| memset | |ダイジェスト|バッファをクリアすることです機密データから、初期化されていないスタックからのデータの後続の読み取りでは、機密情報を取得することは不可能でした。

一部のコンパイラは、プログラムのどこかでコードが間違っていると考えて、条件付きチェックを削除できると考えています。たとえば、次のコードスニペットを見つける

  call_fn(ptr); //   ptr. //    if (ptr == NULL) { error("ptr must not be NULL"); }

一部のコンパイラは、条件| ptr == NULL | そうでなければ、関数| call_fn（）|でそれを間接参照するのは間違っているので、常にFALSEでなければなりません。

解決策

コンパイルされたコードを分析し、すべての命令がそこに存在することを確認します。（これは標準サイズのアプリケーションでは不可能ですが、セキュリティの観点から重要なコードに対しては実行する必要があります）。

コンパイラが実行できる最適化を理解し、安全なプログラミングの原則の観点からそれぞれの効果を慎重に評価します。特に、コードフラグメントまたはブランチを削除する最適化、およびプログラムの残りの部分が正しい場合に「表示されない」エラーを防止するコードフラグメントに注意してください。

可能な限り、コンパイル中にその最適化を無効にして、セキュリティに影響する条件の検証を削除または弱めることを検討してください。

最適化による命令の削除を防ぐために、volatileキーワードを使用して関数をオーバーライドできます。これは、たとえばmemset |をオーバーライドするときにlibotteryで使用されます。

 void * (*volatile memset_volatile)(void *, int, size_t) = memset;

memset_sの呼び出しはC11で導入されており、最適化中の削除は禁止されています。

 #define __STDC_WANT_LIB_EXT1__ 1 #include <string.h> ... memset_s(secret, sizeof(secret), 0, sizeof(secret));

安全なプログラミングインターフェイスと安全でないプログラミングインターフェイスの混同を避ける

問題

悪い決断

機能は、一部のプラットフォームでは安全で、他のプラットフォームでは危険な場合があります。このような場合、プログラマーはこの関数を使用して、自分のコードが安全なプラットフォームで実行されると信じています。コードが他のプラットフォームに移植されて安全でなくなる可能性があるため、これは悪いアプローチです-誰も気付かないでしょう。

プラットフォーム依存の関数を再定義できるシステムでは、一部のプログラマーは安全でない関数を安全なものとしてオーバーライドし、一般に安全ではないプログラムインターフェイスを使用してプログラムを記述します。これは、プログラマーが安全でないように見えるコードを書くという事実につながるため、かなり議論の余地のあるアプローチです。さらに、オーバーライドされたメソッドが機能しない場合、プログラムは安全でなくなり、これを判別できません。そして最後に、これは、そのようなプログラムのコード断片が他のプロジェクトにコピーされた場合、安全でないという事実につながります。

解決策

可能な限り、安全な機能に安全でないオプションを使用しないでください。たとえば、ランダムな初期パディングを使用した堅牢なストリーム暗号に基づくMIFは、ほとんどのアプリケーションで十分に高速です。データ型に依存しないmemcmpの置換は、すべてのメモリ領域比較操作に使用できるほど高速です。

安全でない関数を削除できない場合は、コンパイル段階でエラーが生成されるように再定義するか、静的コード分析用のツールを使用して、安全でない関数の使用を特定して警告します。安全でないオプションを安全なオプションとしてオーバーライドできる場合は、セキュリティを強化するために、安全でないAPIを呼び出さないで、その使用の事実を検出できることを確認してください。

両方のオプション（安全なものと安全でないもの）を残す必要がある場合は、関数名が非常に異なり、誤って安全でないオプションを使用するのが困難であることを確認してください。たとえば、安全なMAPと安全でないMAPがある場合、安全でないオプションに「Random」、「FastRandom」、「MersenneTwister」、または「LCGRand」という名前を付けないでください。代わりに、「InsecureRandom」などの名前を付けます。安全でない関数の使用が常に少し怖いように、プログラミングインターフェイスを設計します。

プラットフォームが安全でないことを示す名前のない関数の安全でないバージョンを提供し、この関数を削除できない場合は、安全な名前のシステムコールラッパーを使用し、コードの静的分析により、安全でない名前のすべての使用を明らかにします。

関数が一部のプラットフォームでは安全で、他のプラットフォームでは安全でない場合は、関数を直接使用しないでください。代わりに、安全なラッパーを定義して使用してください。

同じAPIレベルでセキュリティレイヤーと暗号化プリミティブの抽象化を混在させないでください

問題

ソフトウェアインターフェイスのさまざまな部分に必要な分析の種類が明確でない場合、プログラマは安全に使用できる機能について十分に簡単に間違いを犯す可能性があります。

RSAソフトウェアインターフェースの次の例（発明されたが、実際に見られるものに似ている）を検討してください。

 enum rsa_padding_t { no_padding, pkcs1v15_padding, oaep_sha1_padding, pss_padding }; int do_rsa(struct rsa_key *key, int encrypt, int public, enum rsa_padding_t padding_type, uint8_t *input, uint8_t *output);

「キー」パラメータに詳細のコンポーネントが含まれていると仮定すると、関数は16通りの方法で呼び出すことができ、その多くは無意味で、一部は安全ではありません。

暗号化/復号化	対称/非対称	パディングタイプ	発言
0	0	なし	パディングなしの復号化。偽物の可能性。
0	0	pkcs1v15	復号化PKCS1 v1.5。おそらく、Blainbacherによる攻撃の対象となります。
0	0	あえ	復号化OAEP。良いオプション。
0	0	pss	復号化PSS。意図しないエラーにつながる可能性がある、かなり奇妙なオプション
0	1	なし	パディングなしの署名。偽物の可能性。
0	1	pkcs1v15	署名PKCS1 v1.5。一部のアプリケーションに適していますが、PSS署名を使用することをお勧めします。
0	1	あえ	署名OAEP。一部のアプリケーションに適していますが、PSS署名を使用することをお勧めします。
0	1	pss	署名PSS。非常に良いオプション。
...	...	...	残りのオプション（暗号化と署名の検証）。

この関数を呼び出す16の可能な方法のうち4つだけが安全で、別の6つは安全ではなく、場合によっては残りの6つが使用中に問題を引き起こす可能性があることに注意してください。このようなAPIは、RSAシステムでさまざまな追加メソッドを使用することの意味を理解している開発者にのみ適しています。

ここで、さまざまなモードでのブロック暗号化、キー生成、さまざまなメッセージ認証コードおよび署名用のプログラミングインターフェイスを追加することを想像してください。そのようなプログラムインターフェイスを使用して認証とデータ暗号化を実装する正しい機能を開発しようとするプログラマーには、膨大な選択肢がありますが、安全なオプションの数は明らかに減少します。

解決策

高レベルのプログラミングインターフェイスを提供します。たとえば、強力なアルゴリズムのみを安全に使用するデータの暗号化と認証を実装する機能を提供します。対称および非対称アルゴリズムとその動作モードのさまざまな組み合わせを提供する関数を作成する場合、この関数が安全でないアルゴリズムとその安全でない組み合わせの使用を許可しないことを確認してください。
可能な限り、低レベルAPIを避けてください。ほとんどのユーザーは、パディングなしでRSAを使用したり、ECBモードでブロック暗号を使用したり、ユーザーが選択したランダム値でDSA署名を使用したりする必要はありません。これらの関数は、永続的なものを実現するためのビルディングブロックとして使用できます。たとえば、追加なしでRSAを呼び出す前にOAEPパディングを行い、ブロック1、2、3に対してECBモードで暗号化を使用して...ランダムDSA値にランダムまたは予測不可能なバイトシーケンスを使用しますが、実際には、正しくない場合よりも誤って使用される頻度が高いことが示されています。

特定のプロトコルの実装には他のいくつかのプリミティブが必要ですが、新しいプロトコルの実装にはおそらく適さないでしょう。たとえば、CBC、PKCS1 v1.5、およびRC4を使用せずにブラウザー互換のTLSを実装することはできませんが、これらのプリミティブはいずれも適切なオプションではありません。

経験の浅いプログラマーが使用する暗号化モジュールを提供する場合は、そのような関数を完全に避けて、十分に説明された高レベルの安全な操作を実装する関数のみを選択することをお勧めします。
経験のあるユーザーと経験の浅いユーザーの両方にインターフェースを提供する必要がある場合は、高レベルと低レベルのソフトウェアインターフェースを明確に分離してください。「安全な暗号化」機能は、わずかに変更された引数を持つ「不正な暗号化」と同じ機能であってはなりません。関数と型をパッケージとヘッダーに分離する言語では、安全な暗号関数と安全でない暗号関数を同じパッケージとヘッダーに含めるべきではありません。サブタイプを持つ言語では、安全な暗号化を実現するために個別のタイプが必要です。

符号なしの型を使用して、バイナリデータを表します。

問題

一部のCライクな言語では、符号付き整数型と符号なし整数型は異なります。特に、Cでは、問題はtype | char | iconicは実装に依存します。これは、たとえば次のような問題のあるコードにつながる可能性があります。

 int decrypt_data(const char *key, char *bytes, size_t len); void fn(...) { //... char *name; char buf[257]; decrypt_data(key, buf, 257); int name_len = buf[0]; name = malloc(name_len + 1); memcpy(name, buf+1, name_len); name[name_len] = 0; //... }

解決策

符号付きバイト型と符号なしバイト型を区別する言語では、実装は符号なし型を使用してAPIでバイト文字列を表す必要があります。

機密データのメモリをクリア

問題

ほとんどのオペレーティングシステムでは、最初のプロセスがシステムにメモリを停止または返したため、あるプロセスで使用されたメモリを最初にクリアせずに別のプロセスで使用できます。メモリに秘密キーが含まれている場合、それらは別のプロセスで使用できるため、侵害される可能性が高くなります。マルチユーザーシステムでは、これにより、システムの他のユーザーのキーを決定できます。同じシステム内であっても、このような状況は、以前は比較的「安全な」脆弱性が機密データの漏洩につながる可能性があるという事実につながる可能性があります。

解決策

 void burn( void *v, size_t n ) { volatile unsigned char *p = ( volatile unsigned char * )v; while( n-- ) *p++ = 0; }

強い一致を使用する

問題

多くの暗号システムはランダム性のソースを必要とし、そのようなシステムは、そのようなソースのランダム性からのわずかな逸脱の場合でも安全でなくなる可能性があります。たとえば、DSAで乱数を1つでもリークすると、秘密キーの決定が非常に高速になります。不十分なランダム性を判断するのは非常に困難です。OpenSSLでのDebian乱数ジェネレーターのエラーは2年間気付かれず、多数のキーの侵害につながりました。暗号化アプリケーションの乱数の要件は非常に厳密です。多くの擬似乱数ジェネレーターはそれらを満たしていません。

悪い決断

暗号化アプリケーションの場合

タイムスタンプ、識別子、温度センサーなど、ランダム性の予測可能なソースに依存しないでください。
| rand（）|、| srand（）|、| random（）|などの一般的な擬似乱数生成関数に依存しないでください。ライブラリ| stdlib | または|ランダム| Python言語
Mersenne Twisterジェネレーターは使用しないでください
www.random.orgなどのリソースを使用しないでください（ランダムデータは第三者に知られるか、第三者によって使用される場合があります）。
強力な暗号プリミティブに基づいている場合でも、独自の乱数ジェネレーターを使用しないでください（正確に何をしているのかわからない場合）。
「経済的な」消費のために、アプリケーションの異なる場所で同じランダムビットを使用しないでください。
発電機は、ダイハードまたはNISTテストに合格したという理由だけで安定していると結論付けないでください。
暗号的に堅牢なジェネレーターは、必ずしも前方読み取りと後方読み取りを保護すると結論付けないでください。
ランダムデータとして純粋な形で「ランダム性」を使用しないでください（アナログランダムソースには偏差があることが多いため、そのようなソースから受信したNビットはNランダムビット未満です）。

解決策

プリミティブとその設計を選択することにより、ランダム性の使用を最小限に抑えます（たとえば、 Ed25519を使用すると、決定的な方法で電子署名の曲線を取得できます）。乱数を生成するには、オペレーティングシステムによって提供され、暗号化要件を満たすことが保証されたソース（| / dev / random |など）を使用します。リソースに制限のあるプラットフォームでは、アナログランダムノイズソースと適切な混練手順の使用を検討してください。

センサーが生成した値をチェックして、受信したバイトが本来あるべきものであり、正しく書き込まれていることを確認してください。

Nadi Heninger et al。の記事のセクション7の推奨事項に従ってください。

Ivy Bridgeアーキテクチャ（およびそれ以降の世代）を搭載したIntelプロセッサでは、組み込みのジェネレーターが高いエントロピーと速度を保証します。

Unixシステムは通常、次を使用します| / dev / random | または| / dev / urandom |。ただし、それらのうちの最初のものにはブロッキングプロパティがあります。十分なランダム性が蓄積されていないと考えられる場合、値を返しません。このプロパティは、使いやすさを制限します。

その使用、したがって| / dev / urandom | より頻繁に使用されます。使用| / dev / urandom | 十分簡単：

 #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> int main() { int randint; int bytes_read; int fd = open("/dev/urandom", O_RDONLY); if (fd != -1) { bytes_read = read(fd, &randint, sizeof(randint)); if (bytes_read != sizeof(randint)) { fprintf(stderr, "read() failed (%d bytes read)\n", bytes_read); return -1; } } else { fprintf(stderr, "open() failed\n"); return -2; } printf("%08x\n", randint); /* assumes sizeof(int) <= 4 */ close(fd); return 0; }

ただし、この単純なプログラムでは、ランダム性を安全に生成するには不十分な場合があります。関数| getentropy_urandom |のように、追加のエラーチェックを実行する方が安全です。リブレスル

 static int getentropy_urandom(void *buf, size_t len) { struct stat st; size_t i; int fd, cnt, flags; int save_errno = errno; start: flags = O_RDONLY; #ifdef O_NOFOLLOW flags |= O_NOFOLLOW; #endif #ifdef O_CLOEXEC flags |= O_CLOEXEC; #endif fd = open("/dev/urandom", flags, 0); if (fd == -1) { if (errno == EINTR) goto start; goto nodevrandom; } #ifndef O_CLOEXEC fcntl(fd, F_SETFD, fcntl(fd, F_GETFD) | FD_CLOEXEC); #endif /* Lightly verify that the device node looks sane */ if (fstat(fd, &st) == -1 || !S_ISCHR(st.st_mode)) { close(fd); goto nodevrandom; } if (ioctl(fd, RNDGETENTCNT, &cnt) == -1) { close(fd); goto nodevrandom; } for (i = 0; i < len; ) { size_t wanted = len - i; ssize_t ret = read(fd, (char *)buf + i, wanted); if (ret == -1) { if (errno == EAGAIN || errno == EINTR) continue; close(fd); goto nodevrandom; } i += ret; } close(fd); if (gotdata(buf, len) == 0) { errno = save_errno; return 0; /* satisfied */ } nodevrandom: errno = EIO; return -1; }

Windowsシステムの場合| CryptGenRandom | Win32 APIは、暗号化での使用に適した擬似ランダムビットを生成します。マイクロソフトでは、次のユースケースを提供しています。

 #include <stddef.h> #include <stdint.h> #include <windows.h> #pragma comment(lib, "advapi32.lib") int randombytes(unsigned char *out, size_t outlen) { static HCRYPTPROV handle = 0; /* only freed when program ends */ if(!handle) { if(!CryptAcquireContext(&handle, 0, 0, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT | CRYPT_SILENT)) { return -1; } } while(outlen > 0) { const DWORD len = outlen > 1048576UL ? 1048576UL : outlen; if(!CryptGenRandom(handle, len, out)) { return -2; } out += len; outlen -= len; } return 0; }

Windows XP以降での使用に焦点を合わせている場合、上記のCryptoAPIコードは| RtlGenRandom |

 #include <stdint.h> #include <stdio.h> #include <Windows.h> #define RtlGenRandom SystemFunction036 #if defined(__cplusplus) extern "C" #endif BOOLEAN NTAPI RtlGenRandom(PVOID RandomBuffer, ULONG RandomBufferLength); #pragma comment(lib, "advapi32.lib") int main() { uint8_t buffer[32] = { 0 }; if (FALSE == RtlGenRandom(buffer, sizeof buffer)) return -1; for (size_t i = 0; i < sizeof buffer; ++i) printf("%02X ", buffer[i]); printf("\n"); return 0; }

安全な暗号化プログラミング。パート2ファイナル

セキュリティ上重要なコードの一部に対するコンパイラの改ざんを防止

問題

解決策

安全なプログラミングインターフェイスと安全でないプログラミングインターフェイスの混同を避ける

問題

悪い決断

解決策

同じAPIレベルでセキュリティレイヤーと暗号化プリミティブの抽象化を混在させないでください

問題

解決策

符号なしの型を使用して、バイナリデータを表します。

問題

解決策

機密データのメモリをクリア

問題

解決策

強い一致を使用する

問題

悪い決断

解決策

More articles:

安全な暗号化プログラミング。 パート2ファイナル

セキュリティ上重要なコードの一部に対するコンパイラの改ざんを防止

問題

解決策

安全なプログラミングインターフェイスと安全でないプログラミングインターフェイスの混同を避ける

問題

悪い決断

解決策

同じAPIレベルでセキュリティレイヤーと暗号化プリミティブの抽象化を混在させないでください

問題

解決策

符号なしの型を使用して、バイナリデータを表します。

問題

解決策

機密データのメモリをクリア

問題

解決策

強い一致を使用する

問題

悪い決断

解決策

More articles:

安全な暗号化プログラミング。パート2ファイナル