Androidはデバイスのルート証明書をどこに保存しますか?
動き回る。アイスクリームサンドイッチ(ICS)の登場により、3つの店舗が使用されています。3つのストアは、( /data/misc/keychain
Androidによって提供される)、/data/misc/keychain/cacerts-added
(ユーザーによって追加されたCA)、および/data/misc/keychain/cacerts-removed
(ユーザーによって削除されたCAまたは更新)です。
ICSの前は、にあるBouncyCastleストアを使用していました/system/etc/security/cacerts.bks
。静的ストアであり、変更できませんでした。変更する必要がある場合は、ファームウェアまたはイメージを更新する必要があります。
ストアの説明については、ICSトラストストアの実装を参照してください。そのニコライ・エレンコフのブログ、そして彼は店がどこにあるかだけでなく、システムについて議論する素晴らしい仕事をしています。
OpenSSLをそれらにポイントするにはどうすればよいですか?
OpenSSLが期待するものとAndroidが提示するものは、2つの異なるプレゼンテーション/ストレージ形式であるため、実際にそれを行うことはできません。OpenSSLは、PEM形式のトラストアンカーのコレクションが連結されていることを想定しています。しかし、Androidトラストストアはその形式ではありません。
多くの場合、何が起こるかはダウンロードcacert.pem
です。次に、引数としてSSL_CTX_load_verify_locations
指定することにより、への呼び出しを使用してそれらをロードします。cacert.pem
CAfile
cacert.pem
MozillaやcURLなどの信頼できるソースからダウンロードする場合でも、それを確認して、トラストアンカーのコレクションに満足していることを確認する必要があります。パックには155の潜在的なトラストアンカーがあります。
$ cat cacert.pem | grep BEGIN | wc -l
155
しかし、コメントで述べたように、それは暗黙的にブラウザセキュリティモデルを使用しており、多くの場合、特に良い方法ではありません。
既知のホスト( https://google.comなど)へのHTTPS接続を確立しようとすると、常に「SSL証明書が無効です」というエラーが表示されます。
これに答えるには、GoogleInternetAuthorityまたはGeoTrustGlobalCAをで使用します。ネットキャストを制限するため、GoogleInternetAuthorityを使用するのがおそらく最善です。SSL_CTX_load_verify_locations
Google Internet Authority:
-----BEGIN CERTIFICATE-----
MIID8DCCAtigAwIBAgIDAjp2MA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMTMwNDA1MTUxNTU1WhcNMTYxMjMxMjM1OTU5WjBJMQswCQYDVQQG
EwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzElMCMGA1UEAxMcR29vZ2xlIEludGVy
bmV0IEF1dGhvcml0eSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJwqBHdc2FCROgajguDYUEi8iT/xGXAaiEZ+4I/F8YnOIe5a/mENtzJEiaB0C1NP
VaTOgmKV7utZX8bhBYASxF6UP7xbSDj0U/ck5vuR6RXEz/RTDfRK/J9U3n2+oGtv
h8DQUB8oMANA2ghzUWx//zo8pzcGjr1LEQTrfSTe5vn8MXH7lNVg8y5Kr0LSy+rE
ahqyzFPdFUuLH8gZYR/Nnag+YyuENWllhMgZxUYi+FOVvuOAShDGKuy6lyARxzmZ
EASg8GF6lSWMTlJ14rbtCMoU/M4iarNOz0YDl5cDfsCx3nuvRTPPuj5xt970JSXC
DTWJnZ37DhF5iR43xa+OcmkCAwEAAaOB5zCB5DAfBgNVHSMEGDAWgBTAephojYn7
qwVkDBF9qn1luMrMTjAdBgNVHQ4EFgQUSt0GFhu89mi1dvWBtrtiGrpagS8wEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwNQYDVR0fBC4wLDAqoCig
JoYkaHR0cDovL2cuc3ltY2IuY29tL2NybHMvZ3RnbG9iYWwuY3JsMC4GCCsGAQUF
BwEBBCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL2cuc3ltY2QuY29tMBcGA1UdIAQQ
MA4wDAYKKwYBBAHWeQIFATANBgkqhkiG9w0BAQUFAAOCAQEAJ4zP6cc7vsBv6JaE
+5xcXZDkd9uLMmCbZdiFJrW6nx7eZE4fxsggWwmfq6ngCTRFomUlNz1/Wm8gzPn6
8R2PEAwCOsTJAXaWvpv5Fdg50cUDR3a4iowx1mDV5I/b+jzG1Zgo+ByPF5E0y8tS
etH7OiDk4Yax2BgPvtaHZI3FCiVCUe+yOLjgHdDh/Ob0r0a678C/xbQF9ZR1DP6i
vgK66oZb+TWzZvXFjYWhGiN3GhkXVBNgnwvhtJwoKvmuAjRtJZOcgqgXe/GFsNMP
WOH7sf6coaPo/ck/9Ndx3L2MpBngISMjVROPpBYCCX65r+7bU2S9cS+5Oc4wt7S8
VOBHBw==
-----END CERTIFICATE-----
GeoTrustグローバルCA:
-----BEGIN CERTIFICATE-----
MIIDVDCCAjygAwIBAgIDAjRWMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMDIwNTIxMDQwMDAwWhcNMjIwNTIxMDQwMDAwWjBCMQswCQYDVQQG
EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEbMBkGA1UEAxMSR2VvVHJ1c3Qg
R2xvYmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2swYYzD9
9BcjGlZ+W988bDjkcbd4kdS8odhM+KhDtgPpTSEHCIjaWC9mOSm9BXiLnTjoBbdq
fnGk5sRgprDvgOSJKA+eJdbtg/OtppHHmMlCGDUUna2YRpIuT8rxh0PBFpVXLVDv
iS2Aelet8u5fa9IAjbkU+BQVNdnARqN7csiRv8lVK83Qlz6cJmTM386DGXHKTubU
1XupGc1V3sjs0l44U+VcT4wt/lAjNvxm5suOpDkZALeVAjmRCw7+OC7RHQWa9k0+
bw8HHa8sHo9gOeL6NlMTOdReJivbPagUvTLrGAMoUgRx5aszPeE4uwc2hGKceeoW
MPRfwCvocWvk+QIDAQABo1MwUTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTA
ephojYn7qwVkDBF9qn1luMrMTjAfBgNVHSMEGDAWgBTAephojYn7qwVkDBF9qn1l
uMrMTjANBgkqhkiG9w0BAQUFAAOCAQEANeMpauUvXVSOKVCUn5kaFOSPeCpilKIn
Z57QzxpeR+nBsqTP3UEaBU6bS+5Kb1VSsyShNwrrZHYqLizz/Tt1kL/6cdjHPTfS
tQWVYrmm3ok9Nns4d0iXrKYgjy6myQzCsplFAMfOEVEiIuCl6rYVSAlk6l5PdPcF
PseKUgzbFbS9bZvlxrFUaKnjaZC2mqUPuLk/IH2uSrW4nOQdtqvmlKXBx4Ot2/Un
hw4EbNX/3aBd7YdStysVAq45pmp06drE57xNNB6pXE0zX5IJL4hmXXeXxx12E6nV
5fEWCRE11azbJHFwLJhWC9kXtNHjUStedejV0NxPNO3CBWaAocvmMw==
-----END CERTIFICATE-----
理想的な世界では、プライベートPKIを実行し、サイトとサービスを認証するためにPKIのルートのみを信頼します。公的CAは依拠当事者に対していかなる保証も行わないため、公的CAが何かを証明することを信頼することはありません。基本的に、パブリックCAは、サイトに販売する目的であっても、ウェアーズは良くないと言っています。
次善の世界では、サイトを認定したパブリックCAのみを使用します。つまり、 GoogleInternetAuthorityまたはGeoTrustGlobalCAを使用してGoogleのプロパティを認証します。そうではなく、Diginotarと言います。
他にも、あまり目立たない問題があります。Google Internet Authorityは、 GeoTrustによって認定された制約のない下位CAです。Googleは、Googleのプロパティだけでなく、すべてのサイトに対して証明書を発行することが許可されています。通常、これはRAによって検出されます。これは、発行前にCAへの署名要求を検証する実質的に独立した監査人です。ただし、このモデルでは、リクエストを行う組織(Google)は、リクエストを検証する組織(Google)であり、証明書を発行する組織(Google)と同じです。ブラウザ、CA、およびPKIは、独立監査人が不便すぎたためにチェックアンドバランスとして完全に削除されたことを私が知っている唯一のインスタンスです。
部下がそんなことをしないと思うなら、悲しいことにあなたは間違っているでしょう。CNICCは、制約のない部下の1人が、許可されていないサイトやサービスの証明書を発行しているのを見つけられたため、いくつかのブラウザトラストストアから削除されました。
ブラウザのセキュリティモデルが実際に機能しなくなるのは、間違ったCAがサイトを認証する機能です。また、ユーザーに対するフィッシングの試みの成功も含まれます。つまり、ブラウザは、ユーザーがフィッシングされたために接続が傍受されることを喜んで許可します。
オーバーライドを使用した今後の公開鍵ピンニングが役立つと思われる場合は、悲しいことに誤解されます。彼らはオーバーライドについてほとんど言及していませんが、攻撃者は既知の適切なピンセットを破ることができます。さらに悪いことに、報告機能は、報告してはならないピンセットが壊れている場合は無効になっているため、ブラウザは隠蔽工作に加担しています。
この主題については、もっとたくさんの読み物があります。手始めに、PeterGutmannのEngineeringSecurityとAudunJøsangのインターネットでのTrustExtortionを試してみてください。