インターネット エンジニアリング タスク フォース グループは、リモート プロシージャ コール (RPC) がインターネット上でどのように伝送されるかに注目し、少しの (簡単な) 暗号化が必要であると判断しました。
RPC は 10 年以上更新されておらず、2016 年に暗号化を付与する試み (RFC 7861、RPCSEC) が行われましたが、採用は低調です。
これは問題です。なぜなら、ざっと検索しただけでもRPCを攻撃する方法が数十通り見つかり、Windowsの世界ではRPCの実装はあらゆるプラットフォームで共通しているからです。例えば、2018年4月に発生したこの脆弱性だけでも、Windows XPまで遡ってあらゆるものに影響を与えました。
RPC を暗号化の壁の背後に置くと、プライバシーが向上するだけでなく、インターネットへの直接的な露出がなくなるため、サービス自体の保護にも役立ちます。
そこで、Trond Myklebust 氏 (Networked File System (NFS) の Linux カーネル主任メンテナー) と Oracle の Linux カーネル設計者 Charles Lever 氏は、RPC の保護にもう一度挑戦しています。
このインターネット ドラフトでは、Myklebust 氏と Lever 氏は、RFC 7861 の実現を妨げている問題点として、ホストあたりのコスト管理が比較的困難であること、RFC ヘッダーの一部がクリア テキストのままであること、ホストの CPU リソースを消費する可能性があること、ホスト ID 管理とユーザー ID 管理が異なるセキュリティ ドメインにある場合に困難が生じることなどを挙げています。
もっと深く掘り下げる必要がある: メルトダウンとスペクターの脆弱性により、セキュリティはスタックのさらに下層にまで及ぶことになる
続きを読む
代替案は、「RPC および上位層プロトコルに対して各 RPC 接続のプライバシーを透過的に保護できる」TLS メカニズムを使用することです。
TLS は、信頼機関に対するホストの識別、追加キーの生成、RCP トラフィック用の安全なトンネルのプロビジョニングなどのオーバーヘッドを排除するため、暗号化された RPC の開発を容易にするだけではない、と彼らは主張しています。
トランスポート層の暗号化では上位層のプロトコルもそのまま残り、暗号化/復号化をハードウェアにオフロードできるため、CPU は「大きな RPC 引数と結果」を暗号化または復号化する必要がありません。
RPC over TLS の基本操作単位は と呼ばれる認証フレーバーでありAUTH_TLS、これはサーバーが暗号化をサポートしているかどうかを単純に示します。
TLS を実装していないサーバーは認証エラーで応答するか、STARTTLS文字列なしで応答します。クライアントはそれがサポートされていないことを認識します。それ以外の場合は、TLS ネゴシエーションを開始します。
文書には、RPC-over-RDMA は TLS よりも高レベルのプロトコルであるため、RPC-over-RDMA のユーザーも保護されていると記されています。
既に他の認証メカニズムが導入されている環境では、それらのメカニズムはそのまま残し、TLSはトラフィックの暗号化のみに使用できるとドラフトでは述べられています。RPCSECが実装されている場合は、Kerberosを認証メカニズムとして残し、TLSは「コストのかかる」Generic Security Services (GSS) APIの整合性サービスまたはプライバシーサービスを置き換えることができます。®
