信頼できないデバイスに表示される情報の信頼性
外付けのPC /電話に情報を表示する必要がある（Bluetooth/USB）デバイスがあるとします。表示された情報がそのPCまたは電話のマルウェアによって変更されていないことを保証するための簡単で効果的な方法はありますか？
私が考えた解決策の1つは、デバイスが（秘密キーに基づいて）一意の画像を1回生成し、その画像に情報テキストを毎回描画し、最終結果をスマートフォンに送信することです。攻撃者がテキストを変更しようとすると、画像にギャップが生じ、信頼できるデバイスに保存されている元の背景画像にアクセスできないため、ギャップを埋めることはできません。エンドユーザーが画像を認識し、アーティファクトを注意深く視覚的に検査する限り、それはかなり安全でしょうか？
私が提案したものよりも良い解決策はありますか？
認識できる背景を使用するという考えはかなり良いものです。しかし、T。ポルニンは、そのアプローチに関するいくつかの問題を指摘するのに十分親切でした。
Short：可能な場合は、MobiCoreまたは他のTrustZone実装を使用します。 TEEのない信頼できないデバイスの場合、現在はRich OSのみを使用する必要があります。将来的には、より多くのデバイスがTEEを提供する可能性があります。
信頼と確認に関する問題
最終的には、問題は次のとおりです。デバイスで実行されているコンポーネントとソフトウェアを信頼できない場合、デバイスを信頼して、ユーザーに表示される確認メッセージ/ボタンを変更しないことはできません。
この問題に対する完全な解決策はありません（信頼できないデバイスで確認を求めます）。これは広く知られている事実です。一般に「信頼できる」と見なされるデバイス（ATMなど）には、時々問題が発生します。そのため、銀行およびクレジットビジネスは常にある程度の詐欺を予期しており、それに対処する準備をしています。
信頼できないデバイス
多くのアプリケーションでは、現在、信頼できないモバイルデバイス上でアプリケーションを直接実行することで十分に安全であると見なされています。 （オンラインバンキングなど）
信頼できる実行環境
さらなる信頼を必要とするユースケースのために信頼できる環境を用意することが可能だったらどうでしょうか？ （モバイルコマース、BYODなどの使用例）
ネットワークオペレーターとハードウェアメーカーは、信頼されていないOS（HLOS、リッチOS、汎用OS、または通常の世界のOSとも呼ばれる）のデバイス上の信頼された環境で「信頼されたソフトウェア」を実行するのに役立つ、信頼された実行環境の要件の多くを形式化しました。これらのドキュメントは、OMTP TR0およびOMTP TR1です。これらは、TEEの通常の要件の最も優れたプレゼンテーションの1つです。
TrustZone
ARM + Trusted Logicは10年ほど前にこのアイデアに取り組み始めました。 ARMプロセッサはTrustZoneを導入しました。それはそれ以来ずっと続いています。実際には大体良いアイデアですが、大きな問題はハードウェアのサポートがあることですが、ソフトウェアソリューションは最近までそれをすべて利用していました。
技術的には、1つのリッチOSと1つのセキュアOSを使用することを目的として、TrustZoneを仮想化の制限付きハードウェアサポートと見なすことができます。
G＆D MobiCoreは、主要な携帯電話に採用されている数少ない実装の1つであり、Samsung S3、S4で利用できます。 Samsung Note IIIにはSamsung Knoxがあります。 TrustZoneのMobiCoreにも基づいていると思います。
他のいくつかの電話は他のいくつかのソフトウェアを持っています。多くの場合、電話がソフトウェアで実行できる、またはTrustZoneにロードできるソフトウェアの詳細は入手できません。これは、現在のほとんどすべてのスマートフォンで使用できます。
TrustZone、G＆Dの適切なSWサポートを得るために、ARMとTrusted Logic Mobilityが共同でTrustonicを設立し、次世代のTrusted OSを作成しています。
私はあなたの質問を次のように理解しています：データを生成して無線（Bluetooth）経由で送信する可能性のある具体的なデバイスがあります。そして、前記データを受信して表示する別のデバイス（例えば、スマートフォン）。問題は、2番目のデバイスを信頼できないことです。したがって、問題は次のとおりです。最初のデバイスが送信したものと同じように忠実な表現として表示されるように、データにある程度の信頼を得ることができるかどうかです。
一般的に言えば、いいえ、できません。嘘つきは嘘をつく。 でない限り最初のデバイスが送信するデータには、2番目のデバイスが偽造または偽造できないある種のチェックサムまたは署名が付いています（ デジタル署名 および [〜＃〜] mac [〜＃〜] は、そのための有用な暗号化ツールを証明する可能性があります）、および人間の観察者は、信頼できないスマートフォンとは無関係に検証します。この後者の点が本当の問題です。通常の人間の観察者は、署名検証やMACを頭で計算しません。
このような状況の回避策には、次の2種類があります。
最初のデバイスに直接ディスプレイを追加して、デバイスが潜在的に敵意のあるスマートフォンからの相互作用なしにデータを直接表示できるようにします。これは 支払い端末 で行われます。これらは、基本的にはPCであるキャッシュレジスタにリンクされていますが、最終的にはキャッシュレジスタが信頼されないため、このような端末には独自の画面とキーボードがあります。
3番目のデバイスをダンスに追加します。ユーザーに信頼できるデバイスを提供します。これにより、最初のデバイスによって計算されたMACまたは署名が検証されます。 Mutatis mutandi、これはインターネットであり、信頼されていないスマートフォンが単なるルーターにマッピングされています。送信元と宛先の間のSSLは、ルーターによる誤操作からデータの整合性（および機密性）を保護します。
（この問題は、専用リーダーまたはUSBポートを介してPCに挿入されたスマートカードにも固有の問題であることに注意してください。PINコードを入力すると、PC上にあります。 PCがスマートカードに署名するように要求する内容を把握します。）
既知の画像にテキストをオーバーレイする方法は巧妙ですが、安全ではありません。攻撃者がコンテンツを追加できないようにするものではありません（数値の末尾にゼロを追加することを考えてください。これは有害な場合があります）。さらに、ソース画像の機密性と、「塗りつぶされた」部分を区別する人間の能力に依存しているため、危険です。
最善の解決策は、メッセージをHMACとともに通常どおり表示し、メッセージ全体をHMACで別のデバイスに転記して確認することです。
他に利用できるデバイスがない場合、必要なのは人間が確認できるデジタル署名ですが、ユーザーが気づかない限りコンピュータで変更することはできません。そのようなことはまだ存在しません。ただし、次のようなものは理論的には機能しますが、実際には扱いにくく、人間による改ざんに対して安全ではありません。
- 安全なデバイスと人間の両方が知っているセキュリティワードを作成します。
- メッセージの最後にセキュリティワードを追加します。
- 手動で検証可能なチェックサムアルゴリズムを考え出し、メッセージのチェックサムを計算します。 （このチェックサムは暗号的に安全である必要はないので、手動での計算を簡単にするために修正されたCRC32のようなものでも問題ありません。）
- メッセージの最後にチェックサムを追加する
- CAPTCHAライブラリを使用してメッセージ全体を書き出し、コンピュータがメッセージを読み取れないようにします。
メッセージを改ざんするとチェックサムが破損し、大規模な交換によってセキュリティワードが削除されます。セキュリティワードはコピーできますが、コンピューターはワードを読み取ることができないため、それを含むメッセージの正しいチェックサムを計算することはできません。メッセージの繰り返しや並べ替えから保護したい場合は、ナンスを追加することもできます（単調に増加するメッセージカウンターでできます）。鮮度を重視する場合は、タイムスタンプを追加できます（もちろん、チェックサムを適用する前に）。
警告：このヘアブレインスキームの成功は、CAPTCHA（何度も攻撃に成功している）のセキュリティだけでなく、ユーザーがentireメッセージをエラーなしで作成します。シングルワードCAPTCHAのヒューマンエラーレートは重要なものであるため、検証成功率が非常に低くなり、フラストレーションが生じる可能性があります。同じメッセージが複数回書き込まれて人為的エラー率が低下する可能性がありますが、これによりコンピューターがキャプチャを壊しやすくなります。
その他はすでに技術的な詳細をカバーしています。基本的な原則から直接質問に答えるには：
「[Bluetoothで何かが転送された後。]受信したPCまたは電話で、表示された情報がマルウェアによって変更されていないことを保証する簡単で効果的な方法はありますか？」
答えはノーです、あなたはできません。
あなたの計画は巧妙ですが、基本的に、PCや電話が危険にさらされた場合、それは決して信頼できません。バンキングマルウェアの場合、それらは正しい動作を「エミュレート」するところまで行きますが、実際には別のことをします。あなたのスキームの場合、転送されたものの汚染されていないコピーを保持し、それを使用して画像をレンダリングすることさえできますが、重要なことは何であれ、これは変更された悪意のあるデータの2番目のセットで危険にさらされます。
主な問題は、単一の通信チャネルが危険にさらされると、そこから出てくるものはすべて疑わしいということです。エンドポイントが問題を検出、回復できることを望んでいます。さらに、エンドポイント自体が危険にさらされると、トラフィックの危険はなくなります。エンドポイントの妥協は、捕まる可能性が実際にあるため、試みるべきではないものです。これが、OTPトークンベースのソリューションにトークンの帯域外計算が含まれる理由です。
他の人がすでに指摘したように、信頼できないデバイスが伝えたり見せたりすることは何も信頼できません。そのための信頼できるインターフェース、または作成しようとした検証メカニズムが必要ですが、背景の修復は簡単ではありません。写真家の透かしのようなものが、私と他人の銀行口座に何千ユーロも送金するのに間に合わないようにしたくありません。
オンラインバンキングで（少なくとも）使用されている、ChipTANと呼ばれるソリューションがあります。信頼されていないデバイスがグラフィック表示を表示します（QRを使用できます。ChipTANは、5つの点滅バーのあるアニメーションを使用します。ビルド）して、信頼できるデバイス（ここでは、5つのフォトセンサーと銀行カードのチップに接続するディスプレイを備えた小さなリーダーボックス）でその情報を読み取って表示します。次に、ChipTANデバイスを使用すると、今見た情報に関連付けられたトランザクション認証番号を作成できます。
メッセージが誤って失われて見られなくなることを恐れていますか？メッセージが変更され、実際に10,000ドルを費やしたのに10ドルしか使わなかったと誰かに告げることを恐れていますか？または、マルウェアが1,000ドル未満の金額で確実に動作することを恐れていますが、悪意のある人物が10,000ドルを送金した場合、確認の要求を突然停止しますか？その場合は、リスクが特定のしきい値を超えたときに、サーバー側で信頼できないデバイスを処理する必要がない場合があります。たとえば、1,000ドルを超える金額に対して2要素認証を要求することができるため、すべてのトランザクションで電話を完全に信頼しているわけではありません。電話デバイスをどれだけ信頼する（または信頼しない）かに基づいて制限を設定します。
そして、技術的なソリューションでは制御できないものは、少なくとも監査で対処できることがよくあります。
ユーザーは時々（そしてランダムに）ディスプレイ上の情報が実際にサーバーが送信したものであることを検証できます。彼らはいくつかの異なる方法でこれを行うことができます。物理的にサーバーに行き、そのネイティブディスプレイを見ることができます。彼らは2番目のデバイスを使用できます（おそらく別のベンダーから提供された別のモデルの電話）。 Webブラウザーを介してサーバーに接続し、その方法を再確認できます。または、後で戻ってサーバーのログを確認することもできます。または、サーバーは、SMSまたは電子メールなどのサイドチャネルを使用して確認を提供する2つの方法で情報を送信する場合があります。
ユーザーが4つのメッセージごとに1つをチェックすると、信頼できないデバイスは、偽のメッセージを表示するたびに25％の確率で捕捉される可能性があります。あなたが信頼できないデバイスを制御している悪者である場合、それらは引っ掛かることなくメッセージに長期的なダメージを与えることができるために本当に悪いオッズです。 （これは、ユーザーが監査チェックでランダムであることを必要とします。最後の桁がゼロになるたびに再チェックすることは、攻撃者が悪用する可能性のあるパターンを表します。）
もちろん、脆弱な人々が関わるあらゆる解決策と同様に、問題は勤勉です。最初の1か月間システムの信頼性が証明された場合、ほとんどの人は2か月後にシステムのチェックを停止します。それは人間の性質です。リスクの高い状況での2要素認証は、その問題の解決に役立ちます。
最も重要な情報（たとえば、発信者ID、指紋、または量-使用例に応じて）を表示するデバイス上の小さなディスプレイについて考えることができます。他のいくつかの状況では、偽造が困難なものを使用することができます。たとえば、「確認済み」の音声指紋を行う暗号化ヘッドセットがあります。
また、QRコードを使用して、機密性の高いユーザーが信頼できる（ただし制限された）個人用デバイスでデジタル署名を表示および検証し、信頼できない大きなデバイスを使用して通常の処理を実行することもできます（インターネットカフェの印刷など）。