SecureStringはどのように「暗号化」され、引き続き使用可能ですか？

Question

MSDN SecureStringによれば、コンテンツがで暗号化されており、プログラムがディスクにスワップされると文字列の内容をスニッフィングできないように、安全性を高めるためにが追加されています。

このような暗号化はどのように可能ですか？アルゴリズムは固定されているため、よく知られているかまたは控除可能（業界のアルゴリズムで広く使用されている7つのうちの1つ）であり、プログラムのどこかに鍵が存在する必要があります。そのため、攻撃者は暗号化された文字列を取得し、キーを取得してデータを復号化できます。

このような暗号化はどのように役立ちますか？

Answer 1

私は、鍵を引き出すために使用されるDPAPIについての記事から引用しています。これは、SecureStringに関するほとんどの質問に答える必要があります。

はい、SecureStringには欠点があり、完全に安全ではありません。データにアクセスする方法があります。例えば、Hawkeyeをプロセスに挿入する方法は、SecureStringを抽出する方法としてMSDNに記載されています。私はこの主張を個人的に検証していません。

DAPIキー管理

DAPIは、それが両方の暗号化に同じ鍵を使用してデータを復号化する意味対称ベースの暗号化技術です。 DAPIを使用する方法のいくつかの例に入る前に、DAPIがそのキーを管理する方法について説明する価値があります。ほとんどの場合、DAPIの鍵管理プロセスは不可視であり、一般的にDAPIを心配する必要はありません。これがDAPIが優れたアプローチである主な理由です。

はじめに私は、マスターキーはユーザーのログインパスワードから生成されると書いていました。これは完全な画像ではありません。実際に何が起こるかWindowsは、ユーザーのログインパスワードを使用してマスターキーを生成します。このマスターキーは、ユーザーのパスワードを使用して保護され、ユーザーのプロファイルとともに保存されます。このマスターキーは、他の多くのキーを派生させるために使用され、データを保護するために使用されるこれらの他のキーです。

Windowsがこれを行う理由は、アプリケーションが個別キーを生成するプロセスにエントロピーと呼ばれる追加情報を追加できるようにするためです。ユーザーのログインアカウントで実行されているすべてのアプリケーションが同じキーを使用していて、すべてのアプリケーションがDAPI保護データの保護を解除できるかどうかを確認します。場合によっては、アプリケーションがDAPIで保護されたデータを共有できるようにすることもできます。しかし、時々あなたはしません。アプリケーションがキーの生成にエントロピーを寄与させることによって、そのキーはアプリケーション固有になり、そのアプリケーションによって保護されているデータは、エントロピーを知っていれば再び保護されなくなります。

マスターキーを生成し、そのマスターキーを使用して実際の暗号化を行うための他のキーを生成することは、長年にわたるアプローチのように見えるかもしれませんが、大きな利点があります。ユーザのパスワード保護されたマスターキーとデータの保護に使用される実際のキーとの間には、さらに抽象化レベルがあるため、ユーザがパスワードを変更したときにマスターキーのみを再保護する必要があります。保護されたデータのどれも再保護する必要はありません。マスターキーはデータよりもサイズがはるかに小さいので、大幅なパフォーマンスの節約が行われます。

ユーザーのパスワードが変更されると、もちろん新しいマスターキーが生成されます。この新しいマスターキーは、新しい個別キーを生成するために使用されます。ただし、以前に生成された個々のキーはすべて古いマスターキーから派生しているため、Windowsは以前のすべてのマスターキーを保存する必要があります。 Windowsはマスターキーを忘れることはなく、すべての保護されたデータには、データを保護するために使用されたマスターキーを示すGUIDが設定されています。したがって、適応性の観点から、DAPIは、a）保護されたデータを再保護する必要がないこと、およびb）まだ使用可能なままデータを保護するために使用された鍵を保証しながら、ユーザのパスワードの変更に対処できること、c ）これは自動的にあなたのためにすべて行います。

コンピュータがドメインのメンバーでない限り、DAPIは保護するために使用されたのと同じマシン上の保護されていないデータのみを保護できます。

ユーザーレベルの保護を可能にするだけでなく、そのマスターキーはユーザーのパスワードに基づいており、あるユーザーの保護されたデータは別のユーザーによって保護されないため、DAPIはマシンレベルの保護を提供します特定の情報。マシンレベルのマスターキーを使用すると、アプリケーションのすべてのユーザーが保護されないように、保護されたデータをアプリケーションに保存できます。すでに説明したプロセスの唯一の違いは、マスターキーが、ユーザー固有の情報ではなく、マシン固有の情報から生成されることです。 DPAPIの魔法で

Answer 2

私はコードの一点を見て、Windowsのadvapi32を使ってその汚い作業を行っています。したがって、キーはアプリケーションのメモリに格納されません。それはRtlDecryptMemory（SystemFunction041）で復号化し

RtlEncryptMemory.として良く知られている

[ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)] 
[DllImport("advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)] 
internal static int SystemFunction040([In, Out] SafeBSTRHandle pDataIn, [In] uint cbDataIn, [In] uint dwFlag) 

。

私はコンパイラがSecurityCriticalAttributeで何かをしていると確信しています。

編集これは4.0を使用して反映されました。他のバージョンかもしれない異なっています。

Answer 3

：

このクラスは、データ保護API（DPAPI）保護されたメモリモデルを使用して、そのデータを格納します。つまり、SecureStringの内部に格納されている間は、データは常に暗号化された形式になります。暗号化キーはローカルセキュリティ機関サブシステム（LSASS.EXE）によって管理され、DPAPIを介して、プロセス間通信を介してデータを復号化することができます。

Answer 4

他の人がすでに回答しているように、SecureStringの内容はDPAPIを使用して暗号化されているため、アプリケーションにはキーは保存されず、OSの一部です。私は100％肯定的ではありませんが、SecureStringはユーザー固有のキーを使用すると仮定して、別のプロセスがメモリブロックにアクセスしても単純に復号化するためには同じ資格情報で実行する必要がありますDPAPIを使用するコンテンツ。そうでなくても、マシンキー（理論上は）は、別のシステムに転送された場合に文字列が容易に解読されるのを防ぎます。

さらに重要なのはSecureStringです。使用する場合は&です。これは、拡張された期間、メモリに保持する必要があるが、復号化された形式では頻繁に必要とされない文字列データを格納するために使用する必要があります。ある時点で、それを通常の古いSystem.StringまたはSystem.Char[]に復号化する必要があります。これはメモリ内で最も脆弱なときです。これをあまりにも頻繁に行うと、解読された文字列の複数のコピーが、メモリ内に浮かび上がって収集されるのを待っています。

一般的なルールとして、まれに使用するために保持する必要がある暗号化されたデータ（ログイン資格情報など）を読んでいる場合、これらの資格情報はSecureString、必要に応じてWebサービスコールを行うのに必要なだけの時間だけ解読し、解読されたコピーの寿命はほんの数行に過ぎないことを保証します。

クリティカルブロックやヒントをCLRに使用して、復号化された文字列が使用されている間にコンテキストスイッチしてはいけないということも、メモリがキャッシュされる前にすべての復号化されたコピーが収集される可能性を高めたり、交換された。