Intel Software Guard Extensionsチュートリアル パート5、飛び地の開発

インテルソフトウェアガードエクステンション（インテルSGX）チュートリアルシリーズのパート5では、チュートリアルパスワードマネージャーアプリケーション用のエンクロージャーの開発を完了します。 このシリーズの第4回では、エンクレーブブリッジの機能とC ++ / CLIプログラムのコアとの間のインターフェースレベルとして使用されるDLLライブラリを作成し、エンクレーブのインターフェースも定義しました。 これらのコンポーネントは準備ができているので、飛び地に行くことができます。



シリーズのこのパートと一緒に、ソースコード（エンクレーブ付きの完成したアプリケーション）が提供されます。 このバージョンでは、Intel SGXを使用したコードブランチはハードコーディングされています。

エンクレーブコンポーネント

エンクレーブ内にどのコンポーネントを実装するかを決定するために、アプリケーションのカーネルのクラス図に戻りましょう。これについては、 第3部で最初に説明しました。図を示します。 1.前と同様に、エンクレーブ内のオブジェクトは緑色の影付きで、信頼できないコンポーネントは青色の影付きです。





図1.インテルSoftware Guard Extensionsを使用したチュートリアルPassword Managerのクラス図。



このスキームに従って、エンクレーブに転送する必要がある4つのクラスを定義できます。

• 金庫
• AccountRecord
• 暗号
• DRNG

ただし、作業を開始する前に、アプリケーションデバイスについて決定する必要があります。 このアプリケーションは、Intel SGXをサポートし、Intel SGXを使用しないシステムで動作するはずです。 つまり、既存のクラスをエンクレーブ内で動作するように単純に変換することはできません。 各クラスの2つのバージョンを作成する必要があります。1つはエンクレーブで使用し、もう1つは信頼できないメモリで使用します。 問題は、このデュアルサポートを実装する方法です。

オプション1.条件付きコンパイル

最初のオプションは、エンクレーブと信頼できないメモリの機能を同じソースコードモジュールに実装し、前処理定義と#ifdef命令を使用して、コンテキストに応じて必要なコードをコンパイルすることです。 この方法の利点は、各クラスに必要なソースコードファイルが1つだけであるため、各変更を2か所で適用する必要がないことです。 欠点は、特にバージョン間でいくつかの重要な変更がある場合、そのようなコードがあまり明確でないことです。 さらに、プロジェクトの構造はより複雑になっています。 EnclaveとPasswordManagerCoreの2つのVisual Studio *プロジェクトには共通のソースコードファイルがあり、それぞれに正しいバージョンのソースコードがコンパイルされるように前処理シンボルを指定する必要があります。

オプション2.クラスを分離する

2番目のオプションは、エンクレーブに配置する必要がある各ソースコードファイルを複製することです。 このアプローチの利点は、エンクレーブにソースコードファイルの独自のコピーがあり、直接変更できるため、プロジェクトの構造とコードの表示が簡素化されることです。 ただし、欠点があります。クラスを変更する必要がある場合、エンクレーブのバージョンと信頼できないメモリのバージョンの両方で変更が同じであっても、2つの場所でこれらの変更を行う必要があります。

オプション3.継承

3番目のオプションには、C ++で使用可能なクラス継承の使用が含まれます。 クラスの両方のバージョンに共通の関数は基本クラスに実装され、派生クラスは各コードブランチに関連するメソッドを実装します。 このアプローチの重要な利点は、問題に対する非常に自然でエレガントな解決策であることです。このような状況のために特別に設計された言語の可能性を使用します。 欠点は、プロジェクト構造とコード自体の複雑さが増すことです。



厳密なルールはありません。常にどこでも使用するために決定を下す必要はありません。 一般的な推奨事項は次のとおりです。オプション1は、変更がほとんどないか、簡単に識別できるモジュールに最適です。 オプション2と3は、変更が十分に重要である場合、または結果のソースコードが読み取りと保守の点で複雑すぎる場合に適しています。 選択をスタイルと好みのレベルに減らすと、リストされているアプローチのいずれも完全に機能します。



エンクレーブメモリと信頼できないメモリを対象としたソースコードファイルのバージョンを比較できるため、2番目のオプションを使用します。 このシリーズの今後のリリースでは、コードをよりコンパクトにするための3番目のオプションに進む可能性があります。

エンクレーブクラス

各クラスには、エンクレーブでの動作への適応に関して独自の問題と困難がありますが、すべてのクラスに適用される1つの一般的なルールがあります。リリース前にメモリをゼロで埋める必要がなくなりました。 3番目の部分から思い出すかもしれませんが、これは信頼できないメモリで安全なデータを処理する場合の推奨されるアクションです。 エンクレーブのメモリは、どのハードウェアレベルでも使用できない暗号化キーを使用してプロセッサによって暗号化されるため、リリースされたメモリの内容は他のアプリケーションのランダムデータのように見えます。 これは、エンクレーブ内からすべてのSecureZeroMemory呼び出しを削除できることを意味します。

クラスボールト

Vaultクラスは、パスワードストレージ操作へのインターフェイスです。 すべてのブリッジ機能は、 Vaultクラスの1つ以上のメソッドを介して動作します。 Vault.hからの彼の発表を以下に示します。

class PASSWORDMANAGERCORE_API Vault { Crypto crypto; char m_pw_salt[8]; char db_key_nonce[12]; char db_key_tag[16]; char db_key_enc[16]; char db_key_obs[16]; char db_key_xor[16]; UINT16 db_version; UINT32 db_size; // Use get_db_size() to fetch this value so it gets updated as needed char db_data_nonce[12]; char db_data_tag[16]; char *db_data; UINT32 state; // Cache the number of defined accounts so that the GUI doesn't have to fetch // "empty" account info unnecessarily. UINT32 naccounts; AccountRecord accounts[MAX_ACCOUNTS]; void clear(); void clear_account_info(); void update_db_size(); void get_db_key(char key[16]); void set_db_key(const char key[16]); public: Vault(); ~Vault(); int initialize(); int initialize(const unsigned char *header, UINT16 size); int load_vault(const unsigned char *edata); int get_header(unsigned char *header, UINT16 *size); int get_vault(unsigned char *edata, UINT32 *size); UINT32 get_db_size(); void lock(); int unlock(const char *password); int set_master_password(const char *password); int change_master_password(const char *oldpass, const char *newpass); int accounts_get_count(UINT32 *count); int accounts_get_info_sizes(UINT32 idx, UINT16 *mbname_sz, UINT16 *mblogin_sz, UINT16 *mburl_sz); int accounts_get_info(UINT32 idx, char *mbname, UINT16 mbname_sz, char *mblogin, UINT16 mblogin_sz, char *mburl, UINT16 mburl_sz); int accounts_get_password_size(UINT32 idx, UINT16 *mbpass_sz); int accounts_get_password(UINT32 idx, char *mbpass, UINT16 mbpass_sz); int accounts_set_info(UINT32 idx, const char *mbname, UINT16 mbname_len, const char *mblogin, UINT16 mblogin_len, const char *mburl, UINT16 mburl_len); int accounts_set_password(UINT32 idx, const char *mbpass, UINT16 mbpass_len); int accounts_generate_password(UINT16 length, UINT16 pwflags, char *cpass); int is_valid() { return _VST_IS_VALID(state); } int is_locked() { return ((state&_VST_LOCKED) == _VST_LOCKED) ? 1 : 0; } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明確にするためにE_Vaultと呼ぶこのクラスの飛び地バージョンの宣言は、1つの重要な変更を除いて同一です。



信頼できないコードブランチでは、 Vaultオブジェクトは復号化されたデータベースキーをメモリに保存する必要があります。 パスワードストアを変更するたびに、更新されたデータストアを暗号化し、ディスクに書き込む必要があります。 つまり、キーは自由に使用できる必要があります。 前に4つの方法があります。

1. データベースキーをオンデマンドで生成するために、変更のたびにマスターパスワードを入力するようにユーザーに要求する。
2. ユーザーのメインパスワードをキャッシュして、ユーザーの介入なしにオンデマンドでデータベースキーを生成します。
3. メモリ内のデータベースキーを暗号化、エンコード、または非表示にします。
4. キーを暗号化せずに保存します。

これらのソリューションはどれも満足のいくものではありません。 より便利なソリューションの欠如は、Intel SGXなどのテクノロジーの関連性を再び強調しています。 最初のソリューションは、予約があればより安全であると考えられますが、詳細な動作をするアプリケーションを使用したいユーザーはいません。 2番目のソリューションは、.NET *のSecureStringクラスを使用して実行できますが、デバッガーを介してキーを受信する脆弱性は依然としてあります。 さらに、キーを生成するために特定のコンピューティングリソースが必要になります。これにより、ユーザーのパフォーマンスが許容できないレベルまで低下する可能性があります。 実際、3番目のオプションは2番目と同じくらい安全ではありませんが、パフォーマンスを損なうことはありません。 4番目のオプションはすべての最悪です。



Tutorial Password Managerアプリケーションは3番目のオプションを使用します：データベースキーはXORを使用して128ビット値でエンコードされます。XORを使用して処理した後、リポジトリファイルを開いてこの形式でのみメモリに保存するとランダムに生成されます。 これは基本的にワンタイムキー暗号化スキームです。 キーはデバッガーを実行できるすべてのユーザーが使用できますが、データベースキーが暗号化されていない形式でメモリ内にある時間は制限されています。

 void Vault::set_db_key(const char db_key[16]) { UINT i, j; for (i = 0; i < 4; ++i) for (j = 0; j < 4; ++j) db_key_obs[4 * i + j] = db_key[4 * i + j] ^ db_key_xor[4 * i + j]; } void Vault::get_db_key(char db_key[16]) { UINT i, j; for (i = 0; i < 4; ++i) for (j = 0; j < 4; ++j) db_key[4 * i + j] = db_key_obs[4 * i + j] ^ db_key_xor[4 * i + j]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプローチは明らかに「未知のセキュリティ」モデルを指しますが、ソースコードを公開しているので、特定の未知のことについて話す必要はありません。 より成功したアルゴリズムを選択するか、データベースキーとワンタイムキー（メモリに保存する方法を含む）を非表示にするより多くの努力をすることは可能ですが、選択した方法はデバッガーを使用した表示に対して依然として脆弱であり、非表示アルゴリズムはすべてです同様に公開され、すべての人が利用できます。



ただし、飛び地の内部ではこの問題はなくなります。 メモリはハードウェアベースの暗号化によって保護されているため、データベースキーを復号化した後でも、拡張された権限を持つプロセスであっても、誰もアクセスできません。 したがって、クラスの次のメンバーとメソッドは不要になりました。

 char db_key_obs[16]; char db_key_xor[16]; void get_db_key(char key[16]); void set_db_key(const char key[16]);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらをクラスの1つのメンバー、つまりデータベースキーを保持するchar配列に置き換えることができます。

 char db_key[16];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラスAccountInfo

アカウントデータは、 VaultオブジェクトのメンバーとしてAccountInfoオブジェクトの固定サイズの配列に保存されます。 AccountInfo宣言は 、以下に示すVault.hにもあります。

 class PASSWORDMANAGERCORE_API AccountRecord { char nonce[12]; char tag[16]; // Store these in their multibyte form. There's no sense in translating // them back to wchar_t since they have to be passed in and out as // char * anyway. char *name; char *login; char *url; char *epass; UINT16 epass_len; // Can't rely on NULL termination! It's an encrypted string. int set_field(char **field, const char *value, UINT16 len); void zero_free_field(char *field, UINT16 len); public: AccountRecord(); ~AccountRecord(); void set_nonce(const char *in) { memcpy(nonce, in, 12); } void set_tag(const char *in) { memcpy(tag, in, 16); } int set_enc_pass(const char *in, UINT16 len); int set_name(const char *in, UINT16 len) { return set_field(&name, in, len); } int set_login(const char *in, UINT16 len) { return set_field(&login, in, len); } int set_url(const char *in, UINT16 len) { return set_field(&url, in, len); } const char *get_epass() { return (epass == NULL)? "" : (const char *)epass; } const char *get_name() { return (name == NULL) ? "" : (const char *)name; } const char *get_login() { return (login == NULL) ? "" : (const char *)login; } const char *get_url() { return (url == NULL) ? "" : (const char *)url; } const char *get_nonce() { return (const char *)nonce; } const char *get_tag() { return (const char *)tag; } UINT16 get_name_len() { return (name == NULL) ? 0 : (UINT16)strlen(name); } UINT16 get_login_len() { return (login == NULL) ? 0 : (UINT16)strlen(login); } UINT16 get_url_len() { return (url == NULL) ? 0 : (UINT16)strlen(url); } UINT16 get_epass_len() { return (epass == NULL) ? 0 : epass_len; } void clear(); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクラスがエンクレーブ内で動作するために何もする必要はありません。 SecureZeroFreeへの不要な呼び出しを削除するだけで十分であり、作業は準備完了と見なすことができます。 それにもかかわらず、重要なポイントを示すためにとにかくそれを変更します：飛び地内では、以前にはなかった追加の柔軟性を獲得します。



このシリーズの第3部に戻りましょう：信頼できないメモリスペースのデータを保護するルールの1つは、独自のメモリを管理するコンテナクラス、特に標準テンプレートライブラリのstd ::文字列クラスの使用を拒否することでした。 飛び地の中では、この問題は消えます。 メモリを解放する前にメモリをゼロで埋める必要がないのと同じ理由で、標準テンプレートライブラリ（STL）コンテナがメモリを管理する方法を心配する必要はありません。 エンクレーブのメモリは暗号化されているため、コンテナでの操作後に保護されたデータのフラグメントがそこに残っていても、このデータは他のプロセスで利用できません。



さらに、エンクレーブ内でstd :: stringクラスを使用することには強い議論があります：STLコンテナーのコードは数年にわたって開発者によって徹底的に研究されてきたので、このコードは私たち自身の高レベルの文字列関数（選択がある場合）より安全であると主張できます AccountInfoクラスなどの単純なコードの場合、これはそれほど重要ではありませんが、より複雑なプログラムではこれは非常に便利な利点になります。 ただし、STLコードが追加されるため、DLLのサイズが大きくなります。



E_AccountInfoと呼ぶ新しいクラスの宣言を以下に示します。

 #define TRY_ASSIGN(x) try{x.assign(in,len);} catch(...){return 0;} return 1 class E_AccountRecord { char nonce[12]; char tag[16]; // Store these in their multibyte form. There's no sense in translating // them back to wchar_t since they have to be passed in and out as // char * anyway. string name, login, url, epass; public: E_AccountRecord(); ~E_AccountRecord(); void set_nonce(const char *in) { memcpy(nonce, in, 12); } void set_tag(const char *in) { memcpy(tag, in, 16); } int set_enc_pass(const char *in, uint16_t len) { TRY_ASSIGN(epass); } int set_name(const char *in, uint16_t len) { TRY_ASSIGN(name); } int set_login(const char *in, uint16_t len) { TRY_ASSIGN(login); } int set_url(const char *in, uint16_t len) { TRY_ASSIGN(url); } const char *get_epass() { return epass.c_str(); } const char *get_name() { return name.c_str(); } const char *get_login() { return login.c_str(); } const char *get_url() { return url.c_str(); } const char *get_nonce() { return (const char *)nonce; } const char *get_tag() { return (const char *)tag; } uint16_t get_name_len() { return (uint16_t) name.length(); } uint16_t get_login_len() { return (uint16_t) login.length(); } uint16_t get_url_len() { return (uint16_t) url.length(); } uint16_t get_epass_len() { return (uint16_t) epass.length(); } void clear(); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タグとnonceメンバーは、引き続きchar配列として保存されます。 パスワードは、GCMモードのAESアルゴリズムを使用して、128ビットのキー、96ビットの乱数、および128ビットの認証タグで暗号化されます。 固定サイズの乱数とタグが使用されるため、単純なchar配列よりも複雑な構造にそれらを格納する必要はありません。



std :: stringに基づくこのアプローチにより、ヘッダーファイルでクラスをほぼ完全に定義できることに注意してください。

暗号クラス

Cryptoクラスは暗号化機能を提供します。 このクラスの宣言を以下に示します。

 class PASSWORDMANAGERCORE_API Crypto { DRNG drng; crypto_status_t aes_init (BCRYPT_ALG_HANDLE *halgo, LPCWSTR algo_id, PBYTE chaining_mode, DWORD chaining_mode_len, BCRYPT_KEY_HANDLE *hkey, PBYTE key, ULONG key_len); void aes_close (BCRYPT_ALG_HANDLE *halgo, BCRYPT_KEY_HANDLE *hkey); crypto_status_t aes_128_gcm_encrypt(PBYTE key, PBYTE nonce, ULONG nonce_len, PBYTE pt, DWORD pt_len, PBYTE ct, DWORD ct_sz, PBYTE tag, DWORD tag_len); crypto_status_t aes_128_gcm_decrypt(PBYTE key, PBYTE nonce, ULONG nonce_len, PBYTE ct, DWORD ct_len, PBYTE pt, DWORD pt_sz, PBYTE tag, DWORD tag_len); crypto_status_t sha256_multi (PBYTE *messages, ULONG *lengths, BYTE hash[32]); public: Crypto(void); ~Crypto(void); crypto_status_t generate_database_key (BYTE key_out[16], GenerateDatabaseKeyCallback callback); crypto_status_t generate_salt (BYTE salt[8]); crypto_status_t generate_salt_ex (PBYTE salt, ULONG salt_len); crypto_status_t generate_nonce_gcm (BYTE nonce[12]); crypto_status_t unlock_vault(PBYTE passphrase, ULONG passphrase_len, BYTE salt[8], BYTE db_key_ct[16], BYTE db_key_iv[12], BYTE db_key_tag[16], BYTE db_key_pt[16]); crypto_status_t derive_master_key (PBYTE passphrase, ULONG passphrase_len, BYTE salt[8], BYTE mkey[16]); crypto_status_t derive_master_key_ex (PBYTE passphrase, ULONG passphrase_len, PBYTE salt, ULONG salt_len, ULONG iterations, BYTE mkey[16]); crypto_status_t validate_passphrase(PBYTE passphrase, ULONG passphrase_len, BYTE salt[8], BYTE db_key[16], BYTE db_iv[12], BYTE db_tag[16]); crypto_status_t validate_passphrase_ex(PBYTE passphrase, ULONG passphrase_len, PBYTE salt, ULONG salt_len, ULONG iterations, BYTE db_key[16], BYTE db_iv[12], BYTE db_tag[16]); crypto_status_t encrypt_database_key (BYTE master_key[16], BYTE db_key_pt[16], BYTE db_key_ct[16], BYTE iv[12], BYTE tag[16], DWORD flags= 0); crypto_status_t decrypt_database_key (BYTE master_key[16], BYTE db_key_ct[16], BYTE iv[12], BYTE tag[16], BYTE db_key_pt[16]); crypto_status_t encrypt_account_password (BYTE db_key[16], PBYTE password_pt, ULONG password_len, PBYTE password_ct, BYTE iv[12], BYTE tag[16], DWORD flags= 0); crypto_status_t decrypt_account_password (BYTE db_key[16], PBYTE password_ct, ULONG password_len, BYTE iv[12], BYTE tag[16], PBYTE password); crypto_status_t encrypt_database (BYTE db_key[16], PBYTE db_serialized, ULONG db_size, PBYTE db_ct, BYTE iv[12], BYTE tag[16], DWORD flags= 0); crypto_status_t decrypt_database (BYTE db_key[16], PBYTE db_ct, ULONG db_size, BYTE iv[12], BYTE tag[16], PBYTE db_serialized); crypto_status_t generate_password(PBYTE buffer, USHORT buffer_len, USHORT flags); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクラスのパブリックメソッドは、ストレージでさまざまな高レベルの操作を実行するように変更されています： unlock_vault 、 derived_master_key 、 validate_passphrase 、 encrypt_databaseなど。これらの各メソッドは、1つ以上の暗号化アルゴリズムを呼び出してタスクを実行します。 たとえば、unlock_vaultメソッドは、ユーザーから提供されたパスフレーズを受け取り、SHA-256アルゴリズムに基づいてキー生成関数にパスし、受け取ったキーを使用して、GCMモードでAES-128アルゴリズムを使用してデータベースキーを復号化します。



ただし、これらの高レベルのメソッドは暗号化プリミティブを直接呼び出しません。 これらは、各暗号化アルゴリズムが独立した機能として実装される平均レベルを引き起こします。









図2.暗号化ライブラリの依存関係。



中間層を構成するプライベートメソッドは、暗号化プリミティブに基づいて構築され、図1に示すように、基本的な暗号化ライブラリによって提供される機能をサポートします。 2. Intel SGXを使用しない実装は、Microsoft Cryptography：Next Generation（CNG）APIに依存しますが、エンクレーブは外部DLLに依存できないため、エンクレーブ内で同じライブラリを使用することはできません。 Intel SGX用にこのクラスのバージョンを作成するには、これらの基本機能を、Intel SGX SDKで配布されている信頼できる暗号化ライブラリの機能に置き換える必要があります。 （おそらく、2番目の部分から覚えているように、この理由から、CNGとIntel SGXの信頼できる暗号化ライブラリに共通の暗号化関数を非常に慎重に選択しました。）



E_Cryptoを呼び出すエンクレーブをサポートするCryptoクラスを作成するには、次のプライベートメソッドを変更する必要があります。

 crypto_status_t aes_128_gcm_encrypt(PBYTE key, PBYTE nonce, ULONG nonce_len, PBYTE pt, DWORD pt_len, PBYTE ct, DWORD ct_sz, PBYTE tag, DWORD tag_len); crypto_status_t aes_128_gcm_decrypt(PBYTE key, PBYTE nonce, ULONG nonce_len, PBYTE ct, DWORD ct_len, PBYTE pt, DWORD pt_sz, PBYTE tag, DWORD tag_len); crypto_status_t sha256_multi (PBYTE *messages, ULONG *lengths, BYTE hash[32]);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各メソッドの説明、およびCNGからのプリミティブとサポート関数を、それらの構築に基づいて表1に示します。

方法	アルゴリズム	CNGプリミティブとサポート関数
aes_128_gcm_encrypt	GCMモードでのAES暗号化： •128ビットキー •128ビット認証タグ •追加の検証済みデータの欠如（AAD）	BCryptOpenAlgorithmProvider BCryptSetProperty BCryptGenerateSymmetricKey BCryptEncrypt BCryptCloseAlgorithmProvider BCryptDestroyKey
aes_128_gcm_decrypt	GCMモードでのAES暗号化： •128ビットキー •128ビット認証タグ •AADの欠如	BCryptOpenAlgorithmProvider BCryptSetProperty BCryptGenerateSymmetricKey BCryptDecrypt BCryptCloseAlgorithmProvider BCryptDestroyKey
sha256_multi	SHA-256ハッシュ（オプション）	BCryptOpenAlgorithmProvider BCryptGetProperty BCryptCreateHash BCryptHashData BCryptFinishHash BCryptDestroyHash BCryptCloseAlgorithmProvider

表1.暗号化クラスメソッドと暗号化の比較：次世代（CNG）API関数。



CNGは、暗号化アルゴリズムを非常に正確に制御し、パフォーマンスを向上させる最適化オプションを提供します。 Cryptoクラスは、過度の効率を誇ることはできません。これらのアルゴリズムの1つを呼び出すたびに、基本プリミティブをゼロから初期化し、それらを完全に閉じます。 これは、ユーザーインターフェイスに基づいて動作し、同時に少量のデータを暗号化するパスワードマネージャーにとっては、それほど深刻な問題ではありません。 Webサーバーやデータベースサーバーなどのより強力なサーバーアプリケーションには、より効率的なアプローチが必要です。



Intel SGX SDKで配布される信頼できる暗号化ライブラリのAPIは、CNGよりも中間層に似ています。 同時に、基本的なプリミティブに対する制御の精度は低くなりますが、 E_Cryptoクラスの作成ははるかに簡単です。 表2は、中間層と基本プロバイダー間の新しいマッピングを示しています。

方法	アルゴリズム	Intel SGX Trusted Cryptography Libraryのプリミティブとサポート機能
aes_128_gcm_encrypt	GCMモードでのAES暗号化： •128ビットキー •128ビット認証タグ •追加の検証済みデータの欠如（AAD）	sgx_rijndael128GCM_encrypt
aes_128_gcm_decrypt	GCMモードでのAES暗号化： •128ビットキー •128ビット認証タグ •AADの欠如	sgx_rijndael128GCM_decrypt
sha256_multi	SHA-256ハッシュ（オプション）	sgx_sha256_init sgx_sha256_update sgx_sha256_get_hash sgx_sha256_close

表2. CryptoクラスメソッドとIntel SGX Trusted Cryptography Library関数の比較。

DRNGクラス

DRNGクラスは、Intel Secure Keyテクノロジーのサポートにより利用可能なハードウェアデジタル乱数ジェネレーターへのインターフェイスです。 以前のアクションとの同質性のために、エンクレーブ向けのこのクラスのバージョンはE_DRNGと呼ばれます 。



エンクレーブに適合させるために、このクラスに2つの変更を加えます。 両方の変更は、このクラスのメソッドの内部です。 クラス宣言は同じままです。

CPUID命令

アプリケーションの要件の1つは、CPUがIntel Secure Keyテクノロジーをサポートする必要があることです。 Intel SGXテクノロジーはSecure Keyよりも新しいですが、Intel SGXをサポートするすべてのCPUの将来のすべての世代がIntel Secure Keyもサポートするという保証はありません。 現在、このような状況を予測することは困難ですが、実際には、コンポーネントの1つが存在しない可能性があるコンポーネント間の関係を期待しない方が良いです。 コンポーネントのセットに独立した検出メカニズムがある場合、これらのコンポーネントは相互に依存していないという事実から進める必要があるため、それらの可用性を個別に確認する必要があります。 実際には、これは次のことを意味します。IntelSGXをサポートするCPUがIntel Secure Keyもサポートすることをいくら望んでも、これはどのような場合でも実行しないでください。



Intel Secure Keyが2つの別個のコンポーネントで構成されているという事実により、状況は複雑になっています。各コンポーネントの存在も個別に確認する必要があります。 アプリケーションは、RDRANDおよびRDSEED命令のサポートを定義する必要があります。 Intel Secure Keyテクノロジーの詳細については、Intelの乱数生成（DRNG）ソフトウェア実装ガイドを参照してください 。



DRNGクラスのコンストラクターは、 RDRANDおよびRDSEEDコンポーネントを検出するために必要なチェックを行います 。 組み込みコンパイラー関数__cpuidおよび__cpuidexを使用してCPUID命令に必要な呼び出しを行い、結果で静的なグローバル変数を設定します。

 static int _drng_support= DRNG_SUPPORT_UNKNOWN; static int _drng_support= DRNG_SUPPORT_UNKNOWN; DRNG::DRNG(void) { int info[4]; if (_drng_support != DRNG_SUPPORT_UNKNOWN) return; _drng_support= DRNG_SUPPORT_NONE; // Check our feature support __cpuid(info, 0); if ( memcmp(&(info[1]), "Genu", 4) || memcmp(&(info[3]), "ineI", 4) || memcmp(&(info[2]), "ntel", 4) ) return; __cpuidex(info, 1, 0); if ( ((UINT) info[2]) & (1<<30) ) _drng_support|= DRNG_SUPPORT_RDRAND; #ifdef COMPILER_HAS_RDSEED_SUPPORT __cpuidex(info, 7, 0); if ( ((UINT) info[1]) & (1<<18) ) _drng_support|= DRNG_SUPPORT_RDSEED; #endif }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

E_DRNGクラスの問題は、CPUIDがエンクレーブ内の有効な命令ではないことです。 CPUIDを呼び出すには、 OCALLを使用してエンクレーブを終了し、信頼されていないコードでCPUIDを呼び出す必要があります。 幸いなことに、インテルSGX SDK開発者は、このタスクを大幅に簡素化する2つの便利な関数sgx_cpuidとsgx_cpuidexを作成しました 。 OCALLはこれらの機能を自動的に実行し、 OCALLは自動的に作成されます。 唯一の要件は、EDLファイルがsgx_tstdc.edlヘッダーをインポートする必要があることです。

 enclave { /* Needed for the call to sgx_cpuidex */ from "sgx_tstdc.edl" import *; trusted { /* define ECALLs here. */ public int ve_initialize (); public int ve_initialize_from_header ([in, count=len] unsigned char *header, uint16_t len); /* Our other ECALLs have been omitted for brevity */ }; untrusted { }; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

E_DRNGコンストラクターのシステムコンポーネント検出コードは次のようになります。

 static int _drng_support= DRNG_SUPPORT_UNKNOWN; E_DRNG::E_DRNG(void) { int info[4]; sgx_status_t status; if (_drng_support != DRNG_SUPPORT_UNKNOWN) return; _drng_support = DRNG_SUPPORT_NONE; // Check our feature support status= sgx_cpuid(info, 0); if (status != SGX_SUCCESS) return; if (memcmp(&(info[1]), "Genu", 4) || memcmp(&(info[3]), "ineI", 4) || memcmp(&(info[2]), "ntel", 4)) return; status= sgx_cpuidex(info, 1, 0); if (status != SGX_SUCCESS) return; if (info[2]) & (1 << 30)) _drng_support |= DRNG_SUPPORT_RDRAND; #ifdef COMPILER_HAS_RDSEED_SUPPORT status= __cpuidex(info, 7, 0); if (status != SGX_SUCCESS) return; if (info[1]) & (1 << 18)) _drng_support |= DRNG_SUPPORT_RDSEED; #endif }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CPUID命令の呼び出しは信頼できないメモリで行われるため、CPUIDの結果は信頼できません！ この警告は、CPUIDを自分で起動するか、SGX関数を使用するすべての場合に有効です。 Intel SGX SDKは次のアドバイスを提供します。「コードは結果を確認し、脅威を評価して、結果が改ざんされた場合の信頼できるコードへの影響を判断する必要があります。」 トレーニングパスワードマネージャーには3つのオプションがあります。 RDRANDおよび/またはRDSEED命令は見つかりませんでしたが、そのうちの1つで肯定的な結果が偽造されました。 これにより、実行時に無効な命令が原因でエラーが発生し、プログラムがクラッシュします。 RDRAND命令が検出されましたが、否定的な結果が改ざんされています。 これにより、実行時エラーが発生します。 必要なコンポーネントが検出されなかったため、プログラムは正常に終了します。 RDSEED命令が検出されましたが、否定的な結果が改ざんされています。 この場合、プログラムはRDRAND命令の使用に戻り、初期ランダム値を取得しますが、これはパフォーマンスにわずかに影響します。 . , , , ().

RDRAND

RDSEED, RDRAND , , RDSEED ( ). (DRNG) Intel RDRAND, : 512 128- CBC-MAC AES 128- . , , .



Intel SGX seed_from_rdrand CNG . Intel SGX CNG, , Intel SGX SDK. 3.

アルゴリズム	CNG	Intel SGX Trusted Cryptography Library
aes-cmac	BCryptOpenAlgorithmProvider BCryptGenerateSymmetricKey BCryptSetProperty BCryptEncrypt BCryptDestroyKey BCryptCloseAlgorithmProvider	sgx_cmac128_init sgx_cmac128_update sgx_cmac128_final sgx_cmac128_close

3. seed_from_rdrand E_DRNG.



DRNG , Crypto ? , . DRNG , DRNG Crypto ( Crypto DRNG ). , Crypto , , API .

sgx_read_rand?

Intel SGX SDK sgx_read_rand , . :

1. Intel SGX SDK, « C , , rand , srand ., ». sgx_read_rand RDRAND, , , srand rand , C. , C, . , - , , , , CPUID, , .
2. Intel SGX SDK RDSEED. , . RDRAND sgx_read_rand , , .
3. , sgx_read_rand , .

. , , , .

, .



Tutorial Password Manager, -. , ; , Intel SGX.

将来のリリースで

, , Intel SGX. ニュースをフォローしてください！



Intel Software Guard Extensions Tutorial Series .