電話でマルウェアに感染している可能性がある場合の電話による担当者
電話でユーザーに連絡したい場合や、電話の完全性を可能な限り保護する必要がある場合の設定に問題があります。これを最もよく実現する方法で対話を設計する方法について疑問に思っています。
非常に具体的なセキュリティリスクが心配です。連絡している人物がスマートフォンを使用していて、悪意のあるサードパーティのアプリをスマートフォンにインストールしている可能性があります。そして、この悪意のあるアプリが通話の音声を改ざんしようとするのではないかと心配しています。悪意のあるアプリが何らかの形で偽の音声を通話に注入できるのではないかと心配しています。会話の機密性を保護する必要はありません-通話には秘密が含まれていません-でも、通話の完全性には多くの注意を払っています。
私の質問：このリスクを可能な限り最小限に抑えるにはどうすればよいですか？
問題についてさらに詳しく説明します。私にはかなりの自由度があります。
どちらの方向にも電話をかけるように手配できます（ユーザーに電話をかけるか、ユーザーに電話をかけるように手配できます）。
私は通話の内容を制御しているので、さまざまな「CAPTCHAのような」メカニズムを組み込んで、マルウェアではなく人間と話していることをテストしたり、ユーザーに彼に言ったことを繰り返してもらい、それが役立つ場合は、確認の形式としてその逆。
一方向のオーディオチャネルを他の方向よりも効果的に保護できる場合は、その周りのユーザーとの対話を設計できます。たとえば、ユーザーから私への方向（ユーザーが私に言っていること）でオーディオチャネルの整合性を保護することはできても、逆方向では保護できない場合、私はそれに耐えることができます。私は逆の方向にも生きることができます-どの方向を保護できるかを知っている限り。
私の主な焦点は、アプリケーションサンドボックスから抜け出すことができない（たとえば、ルートを取得できない）悪意のあるアプリに対する防御です。ユーザーの電話がroot化されていない、ジェイルブレイクされていない、などと想定しましょう。また、悪意のあるアプリは、アプリケーションサンドボックスによって制限されているサードパーティアプリであると想定しましょう。パーティーアプリ。 （いくつかの特権エスカレーションエクスプロイトを使用してサンドボックスから抜け出すアプリからも防御することが可能であれば、それは素晴らしいボーナスですが、thatの脅威に対する適切な防御はないと思います。サンドボックス内にとどまるアプリに焦点を当てます。）私のアプリケーションでは、改ざんを検出するだけで十分です（もちろん、完全に防ぐことができればさらに良いでしょう）。
では、この脅威に対する最善の防御は何ですか？
制約。ユーザーは一般の一般的なメンバーです。彼らは彼らが持っているどんな電話も持っているでしょう。強制的に別の電話を使用したり、別の電話を与えたりすることはできません。通話を暗号化するために特別なアプリを必要とするのは実用的ではないと思います（とにかくこれが役立つかどうかはわかりません...）。私はそのような多くのユーザーに連絡できるようにする必要があるので、どんなソリューションも拡張する必要があります。ソリューションをできるだけユーザーが使用できるようにしたいと考えています。
私が行った調査。私は、悪意のあるアプリが何をする可能性があるのかを見てきましたAndroid以降ドキュメント化されたAPIを使用するiOS。
IOSでは、悪意のあるサードパーティアプリが通話内容を改ざんする方法を見つけることができませんでした。それが不可能であるという保証はありません。私はそれを行う方法を見つけていません。
Androidでは、この脅威モデルでは、ユーザーが発信した通話の整合性を保護する方法がないようです。悪意のあるアプリは、ユーザーが発信するときを観察し、通話をキャンセルし、マイクとスピーカーを制御し、偽のダイヤラ画面を表示し、実際にマルウェアと話しているときにユーザーに私に話していると思わせることができます。 。悪意のあるアプリには少なくともPROCESS_OUTGOING_CALLSおよびRECORD_AUDIO権限（およびMODIFY_AUDIO_SETTINGS）ですが、ユーザーのインストールしたアプリのいずれかが悪意のある場合に、これが発生する可能性があります。
ただし、対照的に、Androidは、発信されたように見えますtoユーザーは安全である可能性があります-または、少なくとも、ユーザーとの会話は適切に構成されています。アプリは着信があることを検出できます。古いバージョンのAndroidでは、アプリが着信をブロックし、電話が鳴ったり着信の兆候が表示されなかったりする可能性がありました。ただし、 Androidの最近のバージョンでは後者の機能が削除されています。アプリがユーザーに気付かれずに着信をブロックするプログラム的な方法はないようです。さらに、ユーザーが着信を受け入れる場合呼び出しの場合、サードパーティのアプリが呼び出しの内容にアクセスしたり変更したりする方法はないようですが、状況は少しトリッキーですが、私はそれを考えていますis可能 アプリが私からユーザーへの方向でオーディオチャネルをミュートし、オーディオクリップを再生するには（これにはMODIFY_AUDIO_SETTINGS許可。ただし、悪意のあるアプリにもそれがあると仮定します）。そのため、音声をその方向に偽っています。実際には、悪意のあるアプリからのオーディオクリップであるにもかかわらず、オーディオクリップが私からのものであるとユーザーをだまします。ただし、悪意のあるアプリが通話の内容を盗聴する方法はまだ見つかっていないため、通話に十分なランダム性を導入すると、悪意のあるアプリがこの攻撃を行うタイミングを正確に推測できなくなる可能性があります。悪意のあるアプリが間違って推測した場合、何かが間違っていることが明らかになる可能性があります。したがって、悪意のあるアプリが私をだますことを困難にする何らかの相互作用スクリプトを設計できる可能性があることは、少なくとも私にはもっともらしく思えます。
ユーザーがフィーチャーフォンを使用している場合、サードパーティのアプリをインストールできないため、この懸念は解消されます。
ストローマンソリューションの候補です。この調査により、ユーザーに情報Xを伝達するためのプロトコル/スクリプトの候補が導き出されます。
ユーザーを呼び出します。 （私に電話しないでください、私はあなたに電話します。）
私は、ランダムな時間の間、ユーザーと一緒にアイドルチャットを行います。
ユーザーに情報Xを話します。
ユーザーに、この情報Xを繰り返して確認を求める。ユーザーは不意にXを私に言います。
ユーザーに感謝し、さよならを言い、電話を切ります。
ランダムに選択した音楽の一部が、通話中にバックグラウンドで静かに再生されます（つまり、同じ曲が通話全体で再生され、ユーザーは通話中にバックグラウンドで聴くことができます）。
通話の開始時のランダム期間の雑談の目的は、情報Xが通信される時間をランダム化し、悪意のあるアプリが私からユーザーへのオーディオチャネルをミュートして再生することで情報を「上書き」できないようにすることですオーディオクリップ（悪意のあるアプリは、Xが通信された時刻をランダム化したため、これをいつ実行するかわかりません）。悪意のあるアプリisをミュートしてオーディオクリップを再生することにより、なりすましを試みた場合に備えて、ユーザーに私に再度確認する目的があります。音楽の目的は、私からの音声の一部がいつでも置き換えられた場合にユーザーが気付く機会を与えることです。
これは、私が思いつくプロトコルの候補です。私はそれを出発点として、そしてあなたが批評するわらの男としてだけ言及します。うまくいけば、より良い解決策を見つけることができます。たぶん、あなたはこのプロトコルの深刻な問題に気付くでしょう。それはいいです。私は思いつくことができる最良のスキームを探しています、そして私は特定のプロトコルや相互作用のスタイルにコミットしていません-私が使用するプロトコルを教えてください。
アプリケーション設定。気になれば、アプリケーション設定はリモート投票です。ここで、電話チャネルを使用してユーザーの投票を確認し、マルウェアからの保護を行います。検出せずにユーザーの投票を変更する。ただし、オンラインバンキングトランザクションの電話による確認や、トランザクションの1つのステップとして電話による確認を使用するその他の高セキュリティ設定など、他の設定でも優れたソリューションが役立つ場合があります。
関連。参照 悪意のある電話ソフトウェアが通話にMITM攻撃を仕掛けることはありますか？ 。ただし、その質問は、アプリのサンドボックスから抜け出し、ルートレベルの電話へのアクセスを取得する悪意のあるコードの脅威モデルに焦点を当てています。その脅威モデルでは物事は絶望的に見えます。 This質問は、ユーザーが悪意のあるアプリをインストールしていてもマルウェアがアプリのサンドボックスから抜け出せない、わずかに異なる脅威モデルに焦点を当てています。
クライアントが危険にさらされている場合、それは信頼できません。あなたが制御しておらず信頼できないデバイスは、何らかの形で潜在的に誤動作する可能性があります。セキュリティの一部として信頼する場合は、信頼できないサードパーティが信頼できないデバイスの動作を検証する必要があります。
残念ながら、コンピューターは複雑すぎるため、エンドユーザーはここでは多くの支援を得ることができません。一般的なコンピューティングデバイスでは、攻撃者の複雑さに応じて何でも可能です。デバイスの交換、低レベルのゼロデイハックの利用、中間者攻撃の実行と隠蔽などが可能です。エンドユーザーが信頼できないデバイスと信頼できないデバイスを確認する方法はありません。これを回避するために何らかのメカニズムを使用しようとすることは、攻撃者にあなたが言ったことをかなり繰り返してからそれを忘れるように要求するのと少し似ています。
電話の外部に信頼できる電子機器がある場合は、信頼できない電話を使用して、呼び出しのハッシュ可能なコピーを取得し、発信者が提供した安全に署名されたハッシュと比較できます。これにより、少なくともオーディオファイルを聞いて変更されていないことを確認している限り、信頼できないデバイスが信頼できるデバイスを使用して発信者との間で情報を正確に中継していることを確認できます。
信頼できるコンピューターなしでこの複雑なことを行う良い方法はありませんが、それが選択肢でない場合は、信頼できないデバイスを介して通信する必要があります。あなたはこれのためのコンピュータを持っていないので、あなたは安全なクライアントとして話をしている人を使わなければなりません。つまり、ユーザーが頭の中で実行できる暗号化システム（暗号、ワンタイムパッドなど）に制限されます。使用する暗号化システムと同じくらい安全（OTPはより安全ですが、一般的にはデジタルよりもはるかに安全ではありません）。攻撃者は何が言われているかを知らないので、意味のある変更を行う方法を知らず、通信している両方の当事者による秘密の知識が信頼性を検証します。
ここでの回答とコメント、および私が行った他の調査に基づいて要約します。
悪意のあるアプリがサンドボックスから抜け出すことができる場合
アプリがサンドボックスから抜け出すことができる場合、それは絶望的に見えます。アプリはマイクとスピーカーを制御できるため、信頼できる経路がなく、攻撃は簡単です。
繰り返しになりますが、質問では特に、これはアプリがサンドボックスから抜け出すことができない場合に焦点が当てられていると述べています。それでは、これからに焦点を当てましょう。
Android
Androidでは、悪意のあるアプリがサンドボックスから抜け出せなくても、状況は悲惨に見えます。 2つの深刻な問題があります。
まず、悪意のあるAndroidアプリが、ユーザーが発信した通話を傍受し、任意のMITM攻撃を行うことができます。質問に記載されているように、悪意のあるアプリは、ユーザーが発信したときを観察し、電話をキャンセルし、マイクとスピーカーを制御し、偽のダイヤラ画面を表示し、ユーザーが私に話しかけていると思わせることができます実際にマルウェアに話しかけています。悪意のあるアプリには少なくともPROCESS_OUTGOING_CALLSとRECORD_AUDIOの権限（およびMODIFY_AUDIO_SETTINGS）が必要ですが、これはユーザーがインストールしたアプリのいずれかが悪意のある場合に発生する可能性があります。ですから、発信通話は問題ありません。
次に、悪意のあるAndroidアプリが、ユーザーが受信した着信呼び出しを傍受し、それらに対して任意のMITM攻撃を行う可能性があります。 AJヘンダーソンが説明しているように、悪意のあるアプリは着信転送を一時的に設定して、着信を別の番号にリダイレクトすることができます。悪意のあるアプリが実行する必要があるのは、通話転送を設定するために、*21*6661234567#;のようなものに電話をかけることだけです。これにより、後続の呼び出しが666-123-4567（攻撃者によって制御されるもの）に転送されます。これで、攻撃者はこれらの呼び出しを受信し、制限なしに、すべての通話にMITM攻撃を仕掛けることができます。条件付き転送を使用するなどして、このような攻撃をユーザーから隠す方法さえあります。この方法で通話が傍受されたことを通話者が検出する方法を見つけることができません。悪意のあるアプリにはCALL_PHONE権限が必要ですが、悪意のあるアプリがこれを持っている可能性があります。
ですから、Androidでは、私たちは夢中になっています。ユーザーが電話をかけると、傍受される可能性があります。ユーザーに電話がかかってきた場合、着信転送攻撃がそれを傍受する可能性があります。スマートフォンに悪意のあるアプリがある場合、Androidユーザーに音声で安全に連絡する方法はないようです。驚くべきですが、本当です！
iPhone
IPhoneの場合、状況は異なります。私の知る限り、iPhoneでは、サンドボックスから抜け出すことなく、悪意のあるアプリが通話を妨害することはできません。したがって、悪意のあるアプリがサンドボックスから抜け出すことができない場合、どの方向（発信または着信）に関係なく、音声通話を混乱させることはできません。
つまり、iPhoneの方が安全性が高いようです。 iPhoneのユーザーとの音声通話を確立するのは簡単です。電話の悪意のあるアプリでさえ改ざんできない（ここでも、悪意のあるアプリがサンドボックスから抜け出すことができないと想定しています）。
ボトムライン
一番下の行は、誰かに電話をかける必要がある場合、私たちはねじ込まれているということです。ユーザーがどのような種類の電話を使用しているかがわからない場合（そして実際には、コンシューマーアプリケーションの場合はおそらくそうではありません）、Androidのような脆弱なプラットフォームを使用しているかどうかはわかりません。スマートフォンに不正なアプリが存在する場合、またはiOSやフィーチャーフォンなどのより安全なプラットフォームを使用しているかどうかにかかわらず、安全な音声通話を確立することは不可能です。わかりません。また、コンシューマーアプリケーションの場合、1回限りの電話だけで、平均的な人が通りから暗号化された音声を使用するのは現実的ではないでしょう。
だから、状況はよく見えません。
音声通話を信頼できないチャネルとして扱わないのはなぜですか？
一部の回答者は、音声通話を信頼できないチャネルとして扱うのではない理由を尋ねました。答えは簡単です。これは魅力のない解決策につながります。音声チャネルを完全に信頼できないものとして扱う場合、残っている唯一のオプションは、エンドツーエンドの暗号化のようなものです。これは、今日、ほとんどの一般の人が電話を使用していないためです。したがって、音声通話を完全に信頼されていないチャネルとして扱うと、本当に困惑します。答えは、申し訳ありませんが、通りの外の任意の人に電話をかけられるようにしたいのであれば、実行できません。音声通話を完全に信頼できないものとして扱うと、あきらめざるを得なくなります。絶対にやらなきゃいけないなら諦めたくない。
1人または2人の回答者が、音声チャネルisは完全に信頼されていないと主張しました。しかし、彼らはこの主張を支持する証拠を提供しませんでした。少なくともiOSと質問に記載されている脅威モデル（悪意のあるアプリですが、サンドボックスから抜け出すことができないもの）の場合、このアサーションは単に誤っているように見えます。音声チャネルは完全に信頼されていません。
完全に信頼されていないチャネルと部分的に信頼されていないチャネルには重要な違いがあります。たとえば、攻撃者が受動的に傍受できるが、攻撃者がメッセージを変更できないチャネルについて考えてみます。このようなチャネルは完全性を提供しますが、機密性は提供しません。これは、いくつかの目的には十分です。そのようなチャネルを部分的に信頼できないと呼ぶかもしれません。ただし、そのチャネルはsomeの目的には明らかに十分であるため、完全に信頼できないものとして扱うことは、過度の注意になります。
基本的には、これを信頼できないチャネル上の他のプロトコルと同様に扱う必要があります。つまりメッセージを交換し、すべてのメッセージが受信されていることを検証し、変更されていないことを証明する必要があります。この場合、メッセージは話されますが、音声通信の固有のプロパティ（音声の認識、会話が正しく流れるかどうかの認識など）は信頼できないため、ソリューションの形式には重要ではありません。あなたのシナリオ。
メッセージを認証するために人の声に頼ることはできないため（これは合成または再生される可能性があることを示しました）、何らかのメッセージ認証システムでペンと紙の暗号を使用するように依頼する必要があります。信頼できるデバイスがある場合は、暗号化に外部デバイスを使用することもできます。
ワンタイムパッドは最も使いやすく、暗号化、認証（パッドの所有による）、およびリプレイ耐性（パッドは1回しか使用されないため）を提供します。各メッセージは暗号化され、各返信と同様に電話で読み上げることができます。
もちろん、パッドを配布する方法がない場合、これは良くありません。
マルウェアが妄想的に強力でない場合、会話中にバックグラウンドミュージックを再生できます。最後に、その人に、再生中の音楽を教えてもらい、音楽の一時停止に気付いたかどうかを尋ねます（会話が危険にさらされていることを示します）。話者が情報を繰り返すことが安全であれば、繰り返しも機能します。最後に、あなたとあなたのリスナーの両方が、あなたが「意図している」言語以外の言語を流暢に話すことができることを確認できれば。それは高度なマルウェアでさえだましますが、実際には実現するのは困難です。
バックグラウンドミュージックのオプションを使用する場合は、それが非常によく知られていること（リスナーの国歌など）と、ポーズがほとんどないことを確認してください。