最近、州は可能な限りすべての公共サービスを電子形式に移行しようとしています。 アドレス証明書は積極的に発行され、他の証明書は電子政府ポータルを通じて発行されます。 でも可能 結婚登録 ポータルを通じて結婚します。 実際、非常に便利です。 もちろん、欠点もありますが、ほとんどは組織的なものですが、 規制 法律のレベルで、実装のレベルで。 しかし、これは別の質問です。主なことは非常に良い仕事です。 これはすべて良いですが、投稿はそれについてではありません。
明らかに、公共サービスを使用するには、何らかの方法で身元を確認する必要があります。 このため、デジタル署名の使用はずっと前に法的に修正されました。 EDSの使用の基本的な表現はこれです-EDSは手書きの署名と同等です。 多くの人は知りませんが、EDSキーの転送については(以下、EDSキーという用語を使用します。誰もが単にEDSと呼びますが、実際にはこれらは認証と署名用の2組のキーです)。 第三者への転送には、何らかの責任もあります。 明らかに、多くの人々にとってそれは重要ではありません、彼らはすべての深刻さを理解していません。
一般に、この投稿のトピックは、ブラウザーとEDSキーの間のレイヤーであるNCALayerについてです。 セキュリティは、EDSを使用するための脆弱なメカニズムです。
NCALayerとは
Javaおよびブラウザの最新バージョンでの暗号化プロバイダの主要な実装ではアプレットを使用できないため、NSCはブラウザでEDSを使用するための独自のソリューションを考案しました。 このソリューションはNCALayerと呼ばれます。 NCALayerは、ブラウザー、暗号プロバイダー、EDSキーの間の仲介者です。
NCALayerはユーザーのコンピューターにローカルにインストールされます。 NCALayerは次のように動作します-Webソケットサーバーは特定のポートで開き、あらゆる種類のリクエストが送信されます。
接続のすべての詳細を省略して、これまで2つのクエリを検討して、NCALayerがどのように機能するかについての一般的な考えを考えてみましょう。
- ファイルシステム上のキーを選択します。
{ 'method': "browseKeyStore", 'args': ['PKCS12', 'P12', '/home/user'] }
要求を送信した後、NCALayerが存在するマシンで、デジタル署名キーファイルを選択するためのダイアログボックスが開きます。
したがって、キーを選択すると、ソケットを介して次の答えが得られます。
{"result":"/home/user/AUTH_RSA.p12","errorCode":"NONE"} {"errorCode":"NONE"}
注意:NCALayerを使用する場合、クライアントマシン上のファイルへの実際のパスを取得します。
- キーストアへのパスがある場合、さらに作業を行うには、このストアからパスワードを提供する必要があります。 通常、サイトは何らかの方法でフォームを介してこのパスワードを取得します。 これは、データに署名する方法、または電子デジタル署名を付ける方法の例です。
{ "method": "signXml", "args": [ 'PKCS12', '/home/user/AUTH_RSA.p12', '1874abcef234', '!!!', '<login><timeTicket>1517997213006</timeTicket></login>' ] }
回答は投稿しませんが、リクエストに含まれていたxmlの署名部分が含まれています。
繰り返しますが、EDSキーストアからパスワードを取得することは、サイトの肩にかかっています。 つまり、 サイトは常にキーとパスワードがユーザーのどこにあるかを知っています 。そうでないと、作業できません。
NCALayerの現在のバージョンの短所の実装
- 大きなマイナス点が1つあります。ファイルとパスワードへのパスは、EDSを使用しているサイト開発者が利用できます。 NCALayerを使用すると、あらゆる種類のトークンを使用しても、トークンデバイスからのパスワードもサイトに送信されます。 少なくとも現在の実装ではこれが許可されています。
- 各サイトがデータベースに保存できるキーパスとパスワードを保存します。 保存されない場合があります。 一般に、パスとパスワードを保存するかしないかは、これもサイト開発者の良心によるものです。
- キーとパスワードが保存されているパスを知っている場合、どのサイトでもバックグラウンドでの知識なしでデータに署名できます。 繰り返しますが、サイトで電子デジタル署名を使用したことがある場合、サイトはファイルとパスワードへのパスをすでに知っています。 サイトが攻撃者であれば、自宅のどこかにパスワードを保存することが保証されています。
- キーを使用してメディアに直接アクセスすることはできません。 アクセスはNCALayer機能のみに制限されています。
人間のデジタル署名を所有していない場合にegov.kzにアクセスする方法の実際の例
技術的な詳細や実装については詳しく説明しません。 これを行う方法を説明します。
ここで、この脆弱性を悪用するには、egov.kzのログインメカニズムがEDSを介してどのように機能するかを理解する必要があります。 egov.kzを入力するには、egov.kzからのxmlがユーザーによって署名され、サーバーに転送されてチェックされます。 署名が有効な場合は、ログインします。 NCALayer側からのログインプロセスは、次の手順で構成されています。
ポータルはNCALayerに次のデータを要求します-loadSlotList(ここではエラーで答えることができます)、getKeys、getSubjectDN、getNotBefore、getNotAfterおよびsignXml。 NCALayerが別のユーザーからのこのデータを正しく置き換えた場合、それに応じて、システムに正常にログインします。 NCALayerから署名用にsubjectDNとxmlのみを正しく取得することが非常に重要です。
ここで、他の人、メカニズムからegov.kzにアクセスする方法:
- コンピューターで、egov.kzにログインするために署名する必要があるxml文字列を抽出します。 そのため、idp.egov.kzの開発者コンソールで、次のデータを要求する必要があります
document.getElementById('xmlToSign').value
。 - 悪意のあるサイトに座っている適切な人物に署名用のxml行を送信します。 コンピューターのバックグラウンドで、目的のxml文字列に署名します。 さらに、subjectDNを取得します。
- これで、subjectDNと署名されたxmlがあります。
- ここで最も興味深いのは、コンピューター上で必要なデータを提供するNCALayerの作業をエミュレートすることです。
いくつかの声明
- この投稿は、幅広い読者を対象としたものではなく、Web開発の原則を理解している技術者を対象としています。
- NCALayerを使用する脆弱なすべてのリソース。
- 暗号化の知識は必要ありません。
- この脆弱性を悪用するために、NCAからSDKを取得する必要はありません。 したがって、NECは悪意のあるサイトを特定できません。
- NCALayer開発者は、攻撃者がそのようなメカニズムを使用できないことを保証できません。 すべての人に答えるのは愚かなことです。 技術的にはチャンスがあります。
- 脆弱なキーは、ファイルシステムだけでなく、トークンにもあります。
- トークンであっても、デジタル署名キーキャリアからパスワードを確実に照らすことができます。 egov.kzに一度だけログインすれば十分です。 サイトでのパスワードの使用方法は、開発者次第です。
- 私が聞いた限りでは、EDSキーへのパスとパスワードを設定に保存するシステムはすでにあります。
- サイトに脆弱性はありません。NCALayerを介してEDSを使用するだけでは安全ではありません。
更新:
できること
- 不便になりますが、キーを使用するたびに、少なくともパスワードを要求してください。
- Web暗号化APIを促進する
- ...
エミュレーターNCALayer
ユーザーの知識がなくても、バックグラウンドでデータに署名するアプリケーション