指のDPAPI

こんにちは、harazhiteli！



昨年12月に、私は最初にデータ保護アプリケーションプログラミングインターフェイス（略してDPAPI）に出会いました。 次に、Chromeブラウザにログイン/パスワードを保存する方法を学びました 。 私はこのシステムに詳細に指で署名することを約束しました。 うそじゃないので、キャットへようこそ！







まず、DPAPIとは何か、なぜ作成されたのか、誰がそれを必要としているのかという基本から始めましょう。 次に、その仕組みを説明します。

主なものについて簡単に

情報セキュリティの問題は誰もが長い間触れてきました。Microsoftも例外ではありませんでした。オフィスのPC、ホームシステム、サーバー-すべて、ある程度、間違った手の保護が必要でした。

データをオープン形式で保存することは、少なくとも、確実ではありませんでした。 したがって、Windows 2000のリリースにより、DPAPIの初期の未加工バージョンが世界中で見られました。 その主な目的は、コンピューターに保存されているパスワードと機密情報を保護することです。 さらに、このデータの所有者（ユーザー）が保護の存在についても知らないような方法で、このデータはクラッカーが利用できませんでした。 システムのイデオロギーはそれ以来変わっていません。 アルゴリズムは変更され、穴は閉じられましたが、本質は同じでした。

その結果、機密データがユーザー所有者のみに利用可能であり、他の誰にも利用できない本格的なセキュリティシステムが登場しました。

動作原理

これは、DPAPIを使用した簡単なスキームの外観です。

アプリケーションは、パラメーターMysecret（分類する必要のある文字列/バイト）とエントロピー（エントロピー、少し後で説明します。このパラメーターはオプションです）を設定して、OSにアクセスします。

出力はBLOBです。

BLOB - B inary L arge OBオブジェクト。 復号化は逆称です。 これは、本質的にバイナリデータの配列です。 「大きくて形がない。」

このBLOBは、復号化に必要なデータと暗号自体が開かれたフォームに含まれる一種のコンテナです。 アプリケーションはそれを保存し（たとえば、このBLOBをSQLITEデータベースのフィールドの1つにバイトの配列として記録したのと同じChrome）、後で必要に応じて復号化します（スキームの後半）。







これは、同じスキームがどのように見えるかですが、より詳細です。

暗号化プロバイダーは、モジュール形式のハッシュ、暗号化、キー交換、デジタル署名のためのアルゴリズムのセットです。 たとえば、ロシアにはGOSTアルゴリズムとそれらを組み合わせる暗号化プロバイダーがあります。したがって、システムに渡す場合、標準のAES、SHA、RSAの代わりにGOSTが使用されます。 これらはすべてレジストリで構成されます。 その結果、DPAPI自体はどのアルゴリズムが機能するかに違いをもたらさず、「手袋のように」変化するため、システムがユニバーサルになります。



LSAとCryptoAPIについては、Wikipediaからの引用で回答します。

ローカルセキュリティ機関サブシステムサービス（LSASS） 認証サーバーは、個々のコンピューターのローカルユーザーの承認を担当するWindowsオペレーティングシステムの一部です。 サービスがないと、ローカルユーザー（ドメインに登録されていない）のシステムへのログインが原則として不可能になるため、このサービスは重要です。

CryptoAPIは、Windowsアプリケーション開発者に暗号化プロバイダーと連携するための標準機能セットを提供するアプリケーションプログラミングインターフェイスです。 Microsoftオペレーティングシステムの一部です。 Windows 2000以降、ほとんどのCryptoAPI機能がサポートされています。

最も興味深いことはすべてLSAの腸で起こり、人間はそこで何もすることがないので、このプロセスの操作に影響を与えることはほとんど不可能です。

森の中へ

次に、暗号化/復号化スキームについて直接話しましょう。

実際、これらは3つの関数にすぎません。

1）マスターキーを開く

2）暗号化

3）復号化



暗号化、復号化のいずれを実行する場合でも、最初にマスターキーを開く必要があります。



マスターキー （以降MKと呼び ます ）は、対称暗号化アルゴリズムの暗号化キーです（Windows 7ではデフォルトでAESです）。 また、オープン（ID、アルゴリズム..）およびクローズ（キー自体）情報があるBLOBです。

MKはシステムの最も重要な部分であるため、信頼できる保護下にあります。



ここで、開発者にはジレンマがあります。 パスワード（USBキー）を入力してユーザーが取得しないようにすると同時に、何らかの方法でマスターキーを保護する方法を教えてください。 明らかに、このためには、システムの「個人的な」固有の情報を取得する必要があります。 つまり、これはシステムにログインするためのユーザーパスワードです。 システムにログインすると、LSAはこのパスワードを保存し、要求に応じてCryptoAPIが発行します。







実際、これはキー復号化スキームです。

SIDは一意のセキュリティ識別子です。

LSAパスワードキャッシュはログインパスワードのキャッシュであり、そうでない場合はnullが使用されます。

その後、設定が読み込まれます

HMAC （ハッシュベースのメッセージ認証コード、メッセージ識別ハッシュコードの略）。

簡単に言えば、これは同じMD5、SHAに基づいても機能する同じハッシュ関数です...ハッシュを取得するには、パスワードも必要です。つまり、1つのパラメーターの代わりに2つあります。

PBKDF2-パスワードベースのキー派生関数。 パスワードベースのキー生成標準。 擬似ランダム関数を使用してキーを取得します。 キーの長さに制限はありません。 実際、これはハッシュアルゴリズムの「複雑さ」です。 同じSHA256が1秒未満で計算される場合、その助けを借りて計算は0.1秒にドラッグされます。 ここで重要なパラメーターは、反復回数です。 私のコンピューターにはデフォルトで17400がありますが、アルゴリズムがより長く実行されるほど、選択が難しくなります。 アルゴリズムの詳細を詳しく調べなければ、SHA256アルゴリズムを17,400回実行すると想像できます。

SHA（SHA（SHA ... SHA（文字列））...）

これを達成するには時間がかかり、SHAは神話的な単方向関数であると主張しているため、出力は一意になります。

アルゴリズムが1回（ユーザーの観点から）実行される場合、0.1秒は何もありませんが、繰り返し処理するのは悪夢です。

MasterKey BLOBは暗号化されたキーを持つ単なるデータですが、ソルト、マスターキーID、その他のサービスパラメーターなど、システムが読み取り可能なオープンデータも保存します。



その結果、出力でキーを取得します。



暗号化を開始しましょう。







ここではすべてが非常に簡単です。最初に、キーであるHMACKEY1（システムによってランダムに生成されます）と入力したエントロピー（もう少し、それについて詳しく説明します）がHMACアルゴリズムアナログ（現在3つの入力パラメーターを持っています）に供給されます。 受信したデータは、暗号化されたデータの秘密鍵です。 ソルトもランダムに生成されます。 このデータはすべて、BLOBを作成するときに使用されます。BLOBは、暗号化要求のためにプログラムに既に返されます。



復号化も同様です。







ここでは、必要なすべてのデータがBLOB自体から読み取られます。 出口で、秘密を取得します。



マスターキーBLOBには、読み取り用に開かれた多くの情報があります。 DPAPIバージョン、そのID、さまざまなフラグ、MKサイズ、ソルト、反復カウント、ハッシュアルゴリズム、暗号化。



暗号化されたデータを使用したBLOB'eも多くの情報です。 繰り返しになりますが、暗号化プロバイダーが使用するバージョンID MKは、暗号化、説明、および署名（ハッシュ量）に使用されました。

「最初に戻る」

それとは別に、 CredHistoryのようなことに注意したいと思います。







資格履歴。 一見-不必要なことですが、それは起こります。

パスワードを変更したとしましょう。 アルゴリズムの観点からは、マスターキーにアクセスできなくなりました。 解読するものは何もありません！ しかし、このニュアンスは考え抜かれています。 システムはマスターキーを再暗号化します。 しかし、このプロセスには時間がかかります...多くのキーウィザードが存在する可能性があり、それらすべてを再暗号化する必要があります（既定では、セキュリティを強化するために90日ごとに新しいものが生成され、既に暗号化されたデータは特定のキーに関連付けられています）。 したがって、Microsoftはこのアルゴリズムを作成しました。 前のパスワードは忘れられません...現在のパスワードで暗号化され、スタックに保存されます。 したがって、システムが突然マスターキーを解読できなかった場合、あきらめることはありません。 現在のパスワードを使用して、彼女はCredHistの最初のエントリを解読します。 そして、彼は受け取ったパスワードでマスターキーを再び解読しようとします。 いや？ このパスワードを使用して、彼女はチェーン内の次のパスワードを解読します。 このプロセスは、パスワードがチェーン内でなくなるか、マスターキーが復号化されるまで続きます。 MKが復号化されないのはどうしてですか？ たとえば、サードパーティのソフトウェアを使用してパスワードを強制的にリセットした場合。 通常、このようなソフトウェアはDPAPIキーの「再暗号化」をトリガーしません。 そのため、このような手順の後、このシステムによって保存されたすべてのパスワードが失われます。 しかし、その後パスワードをCredHistにあるものに変更すると、すべてのパスワードが有効になります。

子供連れのゲストがあなたのところに来たと想像してください。 子どもがかかった-とパスワードを変更しました。 サードパーティのユーティリティを使用して、パスワードをリセットします。 すべての秘密データにアクセスできなくなりましたが、以前のパスワードを返した後、データは再びあなたのものになります。 パスワードをリセットするためにパスワードがフロッピーディスクによってリセットされた場合、ここでシステムはインデックスの再作成を開始します。 ちなみに、RSAシステムはフロッピーディスクのパスワードをリセットするために使用されます。 暗号化の公開キーと暗号自体はレジストリに保存され、秘密キーはディスケットに保存されます。 パスワードを変更すると、新しいパスワードは公開鍵で暗号化され、上書きされます。

エントロピー

これでエントロピーについて話すことができます。 システムの原理を理解すると、エントロピーなしで（または同じエントロピーで）暗号化されたデータは、同じユーザーから実行されているアプリケーションによって簡単に解読されることがわかりました。 つまり、情報はユーザーのドメイン内で公開されています。 エントロピーは、本質的に、特定の暗号化されたデータのパスワードです。 エントロピーを設定すると、このパラメーターを知らないコンピューター上のソフトウェアはBLOBを解読できません。



MicrosoftはIEでエントロピーを使用する興味深い例を設定しました。 ログイン時のパスワードはレジストリに保存されます。 キー名は、認証が通過するリンクからのハッシュであり、コンテンツは暗号化されたデータです。 したがって、このリンクはエントロピーです。 つまり、このデータを傍受してオープンマスターキーを持っている場合でも、リンクを反復処理する必要があり、その結果、すべてのデータを所有しているため、盗まれたデータを完全に明らかにすることはできません。

スキームは次のとおりです。

1）リンクmysite.ru/login.phpが開きます。

2）IEはこのリンクからハッシュを取得します。

3）IEは、指定されたハッシュに一致する名前をキー名の中から検索します。

4）キー（BLOB）とリンクの内容をエントロピーとして使用して、IEはログインとパスワードで情報を開きます。

ステップ3で一致が見つからなかった場合、これはユーザーがこのページにまだ何も入力していないことを意味します。



Passcapeプロジェクト、特にプロジェクト管理者に感謝の意を表したいと思います。プロジェクト管理者は、DPAPIに関するすべての質問に喜んで（できれば）答えてくれました。 私の知る限り、彼らのアプリケーション「Windows Password Recovery」はユニークで、DPAPIの動作を完全にエミュレートしています。



ご清聴ありがとうございました。ご質問にお答えさせていただきます。