同じシステム上の2つのアプリケーション間の安全な通信
2つの独立したスタンドアロンピースに分割されたソフトウェアを書いています。 1つはすべてのロジックを処理するアプリケーションのようなサービスで、もう1つはフロントエンドとしてのみ機能し、エンドユーザーによる使用を目的としたGUIアプリケーションです。サービスはポートをリッスンし、クライアント（GUI）アプリケーションからの要求を受け入れます。
一部の機密情報はサービスとGUIアプリケーションの間で交換されるため、転送する前に暗号化する必要があります。データを保護する1つの方法は、キーベースの暗号化を使用することですが、キーはディスクのどこかに、またはアプリケーションのソースコードに格納する必要がありますが、キーの使用は避けます。
キーベースの暗号化アルゴリズムを使用せずに、サービスとGUIアプリケーション間の安全な接続を処理するにはどうすればよいですか？
これらはコンピュータセキュリティの黄金律です。「システム管理者特権を持つ有能なユーザーから何かを隠すことは不可能です」と「デバイスに物理的にアクセスできる有能なユーザーは常にシステム管理者に昇格できます」。
マシンを物理的に制御しているユーザーから情報を隠すことはできません。非表示にしようとしているシークレットが本当に重要な場合は、データをマシンに転送せず、自分が制御する場所のどこかで処理を行うべきではありません。
プログラムがユーザーのマシンで実行されています。ユーザーからデータを保護することはできません。それを念頭に置いて、これは私たちが運命にあることを意味しますか？必ずしも。オペレーティングシステムは、プログラムが別のプログラムとプライベートに通信するための豊富なメカニズムを提供します。これにより、別の非特権アプリケーションがプログラムを傍受することはできません。したがって、ユーザー自身からデータを保護することはできませんが、別の非特権プログラムからデータを保護することができます。非特権プログラム間にセキュリティ境界を提供することは、オペレーティングシステムの主な仕事の1つです。
最も単純なのは、匿名のパイプです。パイプを使用すると、プログラム間でデータの単方向ストリームを転送できます。匿名パイプは、Windows、Linux、OSX、およびすべてのUnixライクなシステムで使用できます。親プロセスがその子との間でデータのストリームを送受信できるようにするstdinとstdoutと呼ばれるパイプのペアとして最も一般的に認識される匿名パイプ。匿名パイプは、親子関係を持つプロセス間でのみ使用できます。名前付きパイプもありますが、WindowsとLinux/Unixのようなシステムでは動作が異なります。これについては後で説明します。
別のIPCは、一般的に利用可能なソケットです。ソケットは双方向パイプのようなものです。多くの異なるソケットがありますが、それらは同様に機能します。最も一般的に知られているのはTCPソケット。TCPソケットは、主にマシン間のネットワーク用ですが、ループバックを作成することもできますTCPソケットは、同じマシン内でのみ使用できます。ループバックソケットはプライバシーを提供します（接続するプログラムとリッスンするプログラムのみがソケットを通過するデータを読み取ることができます）が、ソケットの反対側になることができるユーザーを制限するメカニズムは実際には提供しません。
同じマシン内のプロセス間の通信にUnixで使用できるもう1つのタイプのソケットは、Unixドメインソケットです。 Unixドメインソケットは、ファイルシステムの「特別なファイル」としてプログラムに公開され、UNIXファイルシステムのアクセス許可は、ソケットへのアクセスを制御するために使用されます。ドメインソケットは、ソケットファイルにアクセスするための適切なアクセス許可を持たないプログラムからは接続できません。 Unixライクなシステムでは、これは、サービスとGUIがプログラム専用に予約されている同じユーザーまたはグループとして実行され、ソケットファイルのアクセス許可を適切に設定することを意味します。
名前付きパイプに戻りましょう。 Linux/Unixのようなシステムでは、名前付きパイプは一方向であるという点でstdin/stdoutによく似ています。ただし、Windowsでは、名前付きパイプは実際には双方向であり、WindowsのUnixドメインソケットとほぼ同じです。 Windowsの多くの機能と同様に、名前付きパイプはACLで保護されています。
IOSでは物事は少し毛むくじゃらになります。ジェイルブレイクされていないiOSでは、プロセス間通信のvery限定セットのみが許可され、どちらもソケットを提供しません。しかし、iOSのアプリケーションでは、サービスプログラムとGUIプログラムはおそらく実際には同じアプリケーションになるため、アプリケーションの異なるコンポーネント間に直接ストリームを作成できます。ストリームはアプリケーション内でのみアクセスできるため、これも安全です。
Androidでは、ドメインソケットを作成する機能など、IPCのオプションが増えています。 APIは異なりますが、通常のLinuxと概念的には同じです。または、iOSの場合と同じ方法でサービスとGUIを同じアプリケーションにパッケージ化し、インプロセスストリームを使用することもできます。
私はあなたがマシンの唯一のルート/管理者であると思います。
次の2つのオプションのいずれかを使用できます。
- そのマシンの他のユーザーをまったく許可しない
- プロセスを特別なユーザーとして実行し、そのユーザーだけがアクセスできる（読み取り+書き込み）通信メカニズム（名前付きパイプ、UNIXドメインソケットなど）を使用します。
これら2つのオプションのいずれかを使用すると、転送中にデータを暗号化する必要がなくなります。
注：マシンに別の（十分にスキルのある）管理者がいる場合、何も（暗号化キーを含む）非表示にすることはできません。
基本的に、セキュリティは通常、アルゴリズムではなくキーによって担われます。だから、あなたはここで愚か者の用事にいます。ケルコフの原理で述べられているように、「鍵以外のシステムに関するすべてが公開知識であっても、暗号システムは安全でなければなりません」、またはシャノンがそれを再公式化したように、「敵はシステムを知っている」。そのため、なんらかの形で鍵を使用せず、完全に保護された暗号システムを実際に持つことはできません。
tls をタグリストで言及したので、これが原理的にどのように機能するかを思い出させてください。
SSL/TLS（https）の考え方は、クライアントとサーバー間の通信セッションに使用する対称暗号化キーをネゴシエートすることです。クライアントはサーバーに接続し、その公開鍵を要求します（非対称暗号）。キーは証明書の一部として提供され、証明書の認証チェーンを使用して検証できます。その公開鍵と証明書の適切な検証により、クライアントはそれが誰と話しているのかを知ることができます。したがって、彼は情報を安全に送信できます。
その後、クライアントは公開鍵を使用して対称鍵をネゴシエートし、このセッションで互いに通信できます。通信の外部の人のためにキーを導出することはできません（必要に応じて詳細な説明を参照してください https://security.stackexchange.com/a/20833/1574 ）
TLSを使用すると、2つのパートナー間で機密性が確保され、クライアントは認証チェーンを使用してサーバーを認証することもできます。クライアントを認証する必要がある場合、TLSはクライアント証明書もサポートします。