Samsung Knoxが米国政府によって機密使用の承認を受けたが、本当に安全なのか？

Table Of Contents

• Samsung Knoxが米国政府の機密使用のために検証され、承認された
• それはSamsung Knoxが重要な個人の画像/動画/文書を保存する最も安全な方法であることを意味するのか
• Samsung Knoxはどのように脆弱なのか
• 結論として、AresはSamsung Knoxが言われているほど安全ではないことを指摘している。
• Aresからの推奨

Samsung Knoxが米国政府の機密使用のために検証され、承認された

Samsung Electronicsは、そのソリューションが米国政府によって、機密情報の全範囲を扱うための最初のNIAP検証済み消費者モバイルデバイスとして承認されたと発表しました。10件の覚書（MOA）を完了した後、政府はGalaxy S4、Galaxy S5、Galaxy Note 3、Galaxy Note 4、Galaxy Note 10.1（2014年版）、Galaxy Note Edge、Galaxy Alpha、Galaxy Tab S 8.4、Galaxy Tab S 10.5、およびGalaxy IPSEC仮想プライベートネットワーク（VPN）クライアントを商業ソリューションの機密（CSfC）プログラムコンポーネントリストに追加しました。

この成果は、米国政府の共通基準モバイルデバイス基本保護プロファイル（MDFPP）およびVPN保護プロファイル（VPNPP）プログラムの下でのSamsungの成功したテストと認証の直接の結果です。リストされたSamsungデバイスは、機密政府ネットワークおよびデータでの使用が可能です。すべてのデバイスと機能には、Samsung KNOXによって強化されたセキュリティ機能が組み込まれています。

Samsung自身のKnoxサービスの説明も同じ事実を指摘しています

“KNOX Workspaceコンテナは、企業データのセキュリティを提供し、企業アプリケーションのための従業員のデバイス内に安全なゾーンを作成することによって、ユーザーエクスペリエンスを向上させます。また、企業データを静止時および移動中に暗号化します。KNOX Workspaceコンテナは、ユーザーにモバイルデバイス内に隔離された安全な環境を提供し、独自のホーム画面、ランチャー、アプリケーション、ウィジェットを備えて、より簡単で直感的かつ安全な操作を可能にします。コンテナ内のアプリケーションとデータは分離されています。”

DISA承認製品リストは次の場所で見つけることができます: https://www.disa.mil/Services/Network-Services/UCCO.

それはSamsung Knoxが重要な個人の画像/動画/文書を保存する最も安全な方法であることを意味するのか

毎日のように発生する侵害やハッキングにより、ユーザーは個人の画像/文書や動画をオンラインでクラウドに保存することに深刻なリスクを伴います。iCloudハッキングでは、セレブリティでさえハッキングから安全ではないことが証明されました。SnapChatの漏洩は、13歳から17歳の子供たちの画像がそのような漏洩に対して脆弱であることを証明しました。Dropboxの漏洩は、Dropboxに保存することも比較的高いリスクを伴うことを証明しました。

では、ユーザーはそのプライベートな瞬間に撮影した画像や動画をどうするのでしょうか。米国政府の機密使用の承認を受けて、Samsung Knoxはハッカーから安全であることが保証された最初のモバイルデバイスとなりました。ビッグサム自身によって。

多くのSamsung製品には無制限のストレージ（最大64GB）容量が搭載されているため、スペースオプションでは安全ですが、Samsung Knoxは本当にプライベートな文書/画像や動画を安全に保存するためのフォートノックスなのでしょうか。米国政府はそう考えていますが、セキュリティ研究者のAresはそうは思っていません。

実際、Aresは彼のブログでSamsungのKnoxがどのように脆弱であるかを示しました。

Samsung Knoxはどのように脆弱なのか

Aresは彼のブログで脆弱性についての完全なPoCを提供しており、ここに再現されています：

Samsungの電話には、KnoxとKnox EMMという2つのアプリがプリインストールされています。Knox EMMは、モバイルデバイスのための企業向けクラウドベースの管理ソリューションであり、この分析には含まれていません。Knoxアプリに焦点が当てられ、Knoxコンテナと独自のアプリを持つ別の（安全な）ホーム画面を提供します。Knoxの設定は非常に簡単で、KnoxアプリのためにパスワードとPINを設定するだけです。システム内部を見てみると、Knoxは電話にかなりの量のものをインストールします。Knox関連のアプリは/data/data/にあります： com.samsung.klmsagent com.samsung.knoxemm.mdm com.sec.knox.app.container com.sec.knox.containeragent com.sec.knox.eventsmanager com.sec.knox.seandroid com.sec.knox.store さらに、新しいKnoxホーム画面にインストールされたすべてのアプリは、標準のアプリインストールフォルダ/data/data/にあり、接頭辞com.sec.が付いています。すべてをここにリストするのは多すぎます。典型的なKnoxインストール後には、接頭辞com.sec.が付いた139のアプリとサービスがインストールされます。* システムを少し深く見ると、Knoxはシステム全体に分散しており、いくつかの異なる場所にデータを保存します。たとえば、暗号化されたコンテナ自体は/data/.container_および/data/container/.sdcontainer_1に保存されます。設定用の異なるファイルとデータベースは/data/system/secure_storageおよび/data/system/containerに保存されます。モバイルアプリの分析は、アプリがセットアップ後に保存したファイルの静的分析から始まります。Androidアプリの良い出発点は、/data/data/のアプリフォルダです。これらのフォルダは通常、次の構造を持っています： com.aPackageName |- cache |- databases |- extracted |- lib |- shared_prefs 特に、databasesおよびshared_prefsフォルダは最初に注目されるべきものです。KnoxのContainerAgentアプリ（com.sec.knox.containeragent）には、いくつかの興味深いファイルが保存されていました： Activation.xml ContainerActivator.xml ContainerType.xml CreateSettings.xml DB_BRIDGE_INIT_SYNC.xml DB_BRIDGE_ISCHNDUOS.xml DB_BRIDGE_ONCHANGE_CONTACTS.xml DB_BRIDGE_ONCHANGE_EVENT.xml KLMSLicenseStatus.xml Pref.xml PrivacyPolicy.xml bno.xml com.sec.knox.containeragent_preferences.xml pin.xml はい、pin.xmlファイルには何が書かれていると思いますか？Knoxのセットアップ中に設定したPINが平文で保存されています！ 123456789 さて、Samsung Knoxはユーザーに最大20回のユーザー名とパスワードの試行を許可します。

他のファイルは他に興味深いものを明らかにしませんでした。しかし、pin.xmlファイルに戻りましょう。KnoxにおけるPINの目的は何でしょうか？Knoxを起動するには、データとKnoxホーム画面にアクセスするためにパスワードを提供する必要があります。しかし、テキストフィールドの下に「パスワードを忘れましたか？」という小さなボタンがあります。それをタップすると、PINを提供する必要があります。PINが正しければ、Knoxアプリはパスワードのヒント（パスワードの最初と最後の文字!! + パスワードの元の長さ！）を表示します。これで、Samsung Knoxはデバイスのどこかにパスワードを保存することが明らかです！上記のように、Knoxは/data/data/に設定を保存するだけでなく、/data/system/containerフォルダにはcontainerpassword_1.keyというファイルが保存されています[sic!]。内容は暗号化された文字列です：72C9EE6D56CB15916A4CAB01814F978FA1E2689D（明らかに理由から文字列を変更しました；）。 これはAES暗号化された文字列のようです。今、私たちはアプリを逆コンパイルして、パスワードの暗号化がどのように機能するか、そして暗号化のためのキーがどこから来るのかを詳しく見ていく必要があります。Samsungは、すべてのclasses.dexファイルを削除するためにdex-preoptimizationを利用しており（Javaコードはclasses.dexというファイルに保存され、このファイルはDalvik JVMによって解析されます）、Knoxのapk内で逆コンパイルを少し難しくしています。バイナリを取得するために、/system/app/を見て.odexファイルを見つける必要があります（odexは基本的にアプリケーションのclasses.dexの事前処理されたバージョンで、Dalvik用に実行準備が整っています）。odexファイルはsmaliコードに戻すことができ、その後dexファイルに戻すことができます。最終的にdexファイルはjarファイルに変換され、任意のJavaデコンパイラによって逆コンパイルされることができます。 Samsungはコードの難読化を使用していませんが、実際にはパスワードストレージコードを数百のJavaクラス、継承、およびプロキシ内に隠そうとしました。最終的にKnox Storeアプリでは、他のすべてのアプリがパスワード関連の何かを処理する際に常に呼び出しているプロキシIDataServiceが実装されました。したがって、パスワードを保存する際、アプリは次のように動作します： public boolean setData(String paramAnonymousString) { this.keyGenInput = DataService.this.mPasswordUtil.getInputForKeyGenerate(); String str = SecureKeyLoader.getKeyForPassword(this.keyGenInput, this.bit_size); return DataService.this.mEncryptDecrypt.encryptAndSave(paramAnonymousString, str); } 各行と対応するメソッドを見てみましょう： public long getInputForKeyGenerate() {
return Long.parseLong(SecureKeyLoader.getPartialString(getAndroidID()), 16); } private String getAndroidID() {
return Settings.Secure.getString(this.mContext.getContentResolver(), “android_id”); } したがって、キーの入力は明らかに、すべてのデバイスが持つユニークなAndroid IDです。16バイトのIDがLong値として解析され、その後getKeyForPassword関数の引数として使用されます： public class SecureKeyLoader
{
static
{
System.loadLibrary(“mealy”);
}
public static native String getKeyForPassword(long paramLong, int paramInt);
public static native String getPartialString(String paramString);
} さて、Samsungはそれをますます難読化して、実際のキー生成を隠そうとしています。getKeyForPasswordメソッドは「mealy」と呼ばれるCで書かれた共有ライブラリに配置されています。デバイスからライブラリを取得し、IDAのような逆アセンブラに入れましょう： バイナリには「out_char」というハードコーディングされた文字列があり、次の値を持っています：eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B`_xf+@h#S&wpfv&#。コードを見てみると、getKeyForPasswordメソッドは、getPartialString(getAndroidID())の長い値を引数として受け取り、out_char文字列を変数として持ち、両方をサブルーチン「mealymachine」に渡します。getKeyForPasswordメソッドとmealymachineサブルーチンを擬似コードで見てみましょう： function Java_com_sec_knox_store_SecurityManager_SecureKeyLoader_getKeyForPassword { r4 = r0; //partialString androidID as long value r0 = r2; //integer = 16 r0 = mealymachine(r0, var_8, next, “eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B_xf+@h*#S&wpfv&#”, STK29);* *r3 = *r4;* *r2 = *(r3 + 0x29c);* *r0 = (r2)(r4, r0, r2, r3);* *return r0;* *}* *function mealymachine {* *r6 = r0; //partialString androidID as long value* *r5 = r1; //var_8* *r7 = r2; //next* *r8 = r3; //eu>q5b0KPlLwyb@*#j9?!*ehjl(LHukkA(di^S4UXAChr3B_xf+@h#S&wpfv&#
if (r1 <= 0x64) {
r4 = 0x0;
memset@PLT(0x2144, 0x0, 0x64);
r1 = r4;
do { if (r4 >= r5) { break; } r0 = r6 & 0x1; r6 = r6 >> 0x1;
**(int8_t )(r4 + 0x2144) = (int8_t )(r0 + r8 + r1); //AndroidID + eu>q5b0KPlLwyb@#j9?!ehjl(LHukkA(di^S4UXAChr3B`_xf+@h#S&wpfv&# + var_8
r4 = r4 + 0x1;
r1 = (r0 0x4 + r7 + r1);
} while (true);
r0 = 0x2144;
*(int8_t )(r0 + (r5 & !r5)) = 0x0; return r0; } else { r0 = 0x0; return r0; } return r0; } サブルーチンを見てみると、Android IDの長い値とハードコーディングされた文字列を単に追加しています。getPartialStringメソッドはAndroid IDから一部を引き算します。明確にするために：すべてのアプリは、Secure.getString(getContext().getContentResolver(),Secure.ANDROID_ID);を呼び出すことでシステムにAndroid IDを要求できます。*

結論として、AresはSamsung Knoxが言われているほど安全ではないことを指摘している。

Samsungは、キーを生成する機能を隠そうと本当に努力しましたが、結局はAndroid IDとハードコーディングされた文字列を組み合わせて暗号化キーを生成しています。Knoxと呼ばれる製品からは、異なるアプローチを期待していました：

キーは、より強力でランダム性の高いキーを生成するパスワードベースのキー導出関数2（PBKDF2）から導出されるべきです。 パスワードヒント機能のためにキーを保存しているという事実は、その製品のセキュリティを完全に損なっています。このような製品では、パスワードはデバイスに保存されるべきではありません。必要なのは、パスワードを忘れた場合だけです。しかし、その場合、データは失われるべきであり、そうでなければ、何らかの回復オプションがある場合は安全ではありません。

Aresからの推奨

Samsung Knoxの代わりに、組み込みのAndroid暗号化機能を使用してデバイス全体を暗号化してください。Androidは、選択した暗号化パスワードからPBKDF2関数を使用し、デバイスに保存することはありません。明らかに、パスワードを忘れた場合はデータにアクセスできなくなりますが、それが良い暗号化のポイントです。

*リソース：モバイルセキュリティブログ