summaryrefslogtreecommitdiffstats
path: root/crypto/rsa_private_key_nss.cc
Commit message (Collapse)AuthorAgeFilesLines
* Move PrivateKeyInfoCodec to rsa_private_key_nss.ccdavidben2016-03-231-0/+481
| | | | | | | | | | It's only used by that one file. BUG=580653 Review URL: https://codereview.chromium.org/1829933002 Cr-Commit-Position: refs/heads/master@{#382979}
* Switch to standard integer types in crypto/.avi2015-12-211-5/+6
| | | | | | | | | | BUG=138542 TBR=rsleevi@chromium.org NOPRESUBMIT=true Review URL: https://codereview.chromium.org/1539353003 Cr-Commit-Position: refs/heads/master@{#366460}
* Reland "Don't use RSAPrivateKey in NSS integration code."davidben2015-05-111-207/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a reland of https://codereview.chromium.org/1106103003/ with fixes to ensure callers never pass in a null slot. Currently some NSS platform integration logic transits private keys through RSAPrivateKey on CrOS. This prevents incrementally switching RSAPrivateKey to BoringSSL while keeping platform integrations on NSS. The intent of this change is to clarify RSAPrivateKey as a BoringSSL vs NSS internal crypto library (use_openssl=0 vs use_openssl=1) abstraction. It's primarily to be used with SignatureCreator. Code which uses NSS based on use_nss_certs rather than use_openssl because the underlying platform is NSS should call NSS routines directly, or introduce different abstractions. Remove the problematic RSAPrivateKey methods and instead add crypto/nss_key_util.h which contains some helper functions for manipulating NSS keys. This is sufficient to allow consumers of the removed methods to use NSS directly with about as much code. (This should not set back migrating that logic to NSS as that code was already very NSS-specific; those APIs assumed PK11SlotInfo.) nss_key_util.h, like nss_util.h, is built whenever NSS is used either internally or for platform integrations. This is so rsa_private_key_nss.cc can continue to use the helper functions to implement the NSS-agnostic interface. With this, the chimera CrOS configuration should build. The RSAPrivateKey logic is functional with the exception of some logic in components/ownership. That will be resolved in a future CL. BUG=478777,483606 Review URL: https://codereview.chromium.org/1128153003 Cr-Commit-Position: refs/heads/master@{#329227}
* Revert of Don't use RSAPrivateKey in NSS integration code. (patchset #6 ↵spang2015-05-011-26/+207
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | id:100001 of https://codereview.chromium.org/1106103003/) Reason for revert: Causes SEGV during login on Chrome OS BUG=483606 Original issue's description: > Don't use RSAPrivateKey in NSS integration code. > > Currently some NSS platform integration logic transits private keys through > RSAPrivateKey on CrOS. This prevents incrementally switching RSAPrivateKey to > BoringSSL while keeping platform integrations on NSS. > > The intent of this change is to clarify RSAPrivateKey as a BoringSSL vs NSS > internal crypto library (use_openssl=0 vs use_openssl=1) abstraction. It's > primarily to be used with SignatureCreator. Code which uses NSS based on > use_nss_certs rather than use_openssl because the underlying platform is NSS > should call NSS routines directly, or introduce different abstractions. > > Remove the problematic RSAPrivateKey methods and instead add > crypto/nss_key_util.h which contains some helper functions for manipulating NSS > keys. This is sufficient to allow consumers of the removed methods to use NSS > directly with about as much code. (This should not set back migrating that > logic to NSS as that code was already very NSS-specific; those APIs assumed > PK11SlotInfo.) > > nss_key_util.h, like nss_util.h, is built whenever NSS is used either > internally or for platform integrations. This is so rsa_private_key_nss.cc can > continue to use the helper functions to implement the NSS-agnostic interface. > > With this, the chimera CrOS configuration should build. The RSAPrivateKey logic > is functional with the exception of some logic in components/ownership. That > will be resolved in a future CL. > > BUG=478777 > > Committed: https://crrev.com/a46a990b2ccae2b66e87b5f76d2866044dc3182e > Cr-Commit-Position: refs/heads/master@{#327909} TBR=rsleevi@chromium.org,pneubeck@chromium.org,dpolukhin@chromium.org,caitkp@chromium.org,davidben@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=483606 Review URL: https://codereview.chromium.org/1118263003 Cr-Commit-Position: refs/heads/master@{#327978}
* Don't use RSAPrivateKey in NSS integration code.davidben2015-05-011-207/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently some NSS platform integration logic transits private keys through RSAPrivateKey on CrOS. This prevents incrementally switching RSAPrivateKey to BoringSSL while keeping platform integrations on NSS. The intent of this change is to clarify RSAPrivateKey as a BoringSSL vs NSS internal crypto library (use_openssl=0 vs use_openssl=1) abstraction. It's primarily to be used with SignatureCreator. Code which uses NSS based on use_nss_certs rather than use_openssl because the underlying platform is NSS should call NSS routines directly, or introduce different abstractions. Remove the problematic RSAPrivateKey methods and instead add crypto/nss_key_util.h which contains some helper functions for manipulating NSS keys. This is sufficient to allow consumers of the removed methods to use NSS directly with about as much code. (This should not set back migrating that logic to NSS as that code was already very NSS-specific; those APIs assumed PK11SlotInfo.) nss_key_util.h, like nss_util.h, is built whenever NSS is used either internally or for platform integrations. This is so rsa_private_key_nss.cc can continue to use the helper functions to implement the NSS-agnostic interface. With this, the chimera CrOS configuration should build. The RSAPrivateKey logic is functional with the exception of some logic in components/ownership. That will be resolved in a future CL. BUG=478777 Review URL: https://codereview.chromium.org/1106103003 Cr-Commit-Position: refs/heads/master@{#327909}
* Initial support for using BoringSSL with NSS certificates.davidben2015-04-221-16/+16
| | | | | | | | | | | | | | | | | | | | | | | This switches the USE_OPENSSL Linux and CrOS builds to continue setting USE_NSS_CERTS. This lets it use BoringSSL for the crypto and SSL stack and NSS for certificate verification. See design doc for details on the flags: https://docs.google.com/document/d/1x4DOCKwFkAxl9MGfd6snIzFigO4ku6Shuci0r5BzasQ/edit On Linux, only client auth and OCSP stapling are missing. On ChromeOS, there are some problematic USE_NSS_CERTS APIs in RSAPrivateKey to resolve. We also still need to resolve crbug.com/347404 to maintain parity. As a follow-up, USE_OPENSSL_CERTS on non-Android can now be removed (it was never supported anyway). BUG=462040 Review URL: https://codereview.chromium.org/881213004 Cr-Commit-Position: refs/heads/master@{#326222}
* Rename USE_NSS to USE_NSS_CERTS.davidben2015-04-171-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USE_NSS is confusing because it's not actually the analog of USE_OPENSSL; it's the analog to USE_OPENSSL_CERTS. This is in preparation for the chimera build which will set USE_OPENSSL and USE_NSS(_CERTS). This CL was partially done automatically by the following command: git grep -l USE_NSS | xargs sed -i -e 's/defined(USE_NSS)/defined(USE_NSS_CERTS)/' The remaining were caught by the following command and fixed manually: git grep 'USE_NSS\([^_]\|$\)' Finally, the following command verified nothing in a separate repository was sensitive to this change: find . -name '*.cc' -o -name '*.h' | xargs grep 'USE_NSS\([^_]\|$\)' For now, the old name is still defined, but not used within Chromium. A follow-up CL will remove deprecated use_nss and USE_NSS #defines together which will then cause downstream churn. Though from a grep of known downstreams, the churn seems to be fairly minimal. The removal is split from this CL so that, if we need to revert, the CL to revert is small. TBR=pneubeck@chromium.org BUG=462040 Review URL: https://codereview.chromium.org/1082123003 Cr-Commit-Position: refs/heads/master@{#325710}
* Don't allow trailing data when creating an RSAPrivateKey.davidben2014-11-241-12/+20
| | | | | | | | | | | CreateFromPrivateKeyInfo should not silently discard data after the PrivateKeyInfo. BUG=432279 Review URL: https://codereview.chromium.org/713523004 Cr-Commit-Position: refs/heads/master@{#305503}
* Check trailing data when parsing ASN.1.davidben2014-11-111-0/+3
| | | | | | | | | | | | | | | | | | | Properly check that the entire buffer was consumed. d2i_* may process only a prefix of its input. In addition, don't bother using a memory BIO when the buffer can be parsed directly. This aligns the NSS and OpenSSL port's behavior in most places: SEC_QuickDERDecodeItem fails with SEC_ERROR_EXTRA_INPUT if there is excess data. Add tests. Both for testing and to verify this is the NSS port's behavior. For a PKCS #8 PrivateKeyInfo, NSS will silently accept trailing data. Fix WebCrypto in NSS to align with the spec. RSAPrivateKey is left for a follow-up. (This includes an NSS roll to pick up a symbol export.) BUG=430200 Review URL: https://codereview.chromium.org/685063007 Cr-Commit-Position: refs/heads/master@{#303546}
* Implemented profile-aware owner key loading.ygorshenin@chromium.org2014-05-211-28/+73
| | | | | | | | | BUG=230018 TEST=manual Review URL: https://codereview.chromium.org/270663002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@271802 0039d316-1c4b-4281-b951-d872f2087c98
* NSS: {EC,RSA}PrivateKey shouldn't call crypto::GetPublicNSSKeySlot or ↵mattm@chromium.org2013-11-131-38/+30
| | | | | | | | | | | | | | | | | GetPrivateNSSKeySlot. Make ECPrivateKey use PK11_GetInternalKeySlot for temporary keys. Make ECPrivateKey and RSAPrivateKey "sensitive" functions take slot as parameter. This avoids calling non-thread-safe functions in nss_util on arbitrary threads. Also removes the ANNOTATE_SCOPED_MEMORY_LEAK from RSAPrivateKey which should no longer be necessary. BUG=125848,34742 Review URL: https://codereview.chromium.org/66213002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@234726 0039d316-1c4b-4281-b951-d872f2087c98
* Remove platform-specific implementations of RSAPrivateKey and SignatureCreatorrsleevi@chromium.org2013-06-271-15/+30
| | | | | | | | | | | | | Use NSS/OpenSSL on all platforms, rather than deferring to the underlying OS routines. Because X509Certificate::CreateSelfSigned no longer relies on platform-native types for RSA keys or certificates, it has been moved to x509_util and simply returns a DER-encoded certificate as a string. BUG=none R=wtc Review URL: https://chromiumcodereview.appspot.com/17265013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@208870 0039d316-1c4b-4281-b951-d872f2087c98
* On NSS, treat non-permanent RSA private keys as ephemeralrsleevi@chromium.org2013-06-211-2/+4
| | | | | | | | | | | | | | When generating/using a crypto::RSAPrivateKey with NSS, prefer the internal software slot over other modules (such as any TPMs [ChromeOS] or smart cards [Linux]) if the key being generated is not marked as a permanent key. BUG=none R=wtc Review URL: https://chromiumcodereview.appspot.com/17447009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@207853 0039d316-1c4b-4281-b951-d872f2087c98
* Use a direct include of strings headers in crypto/, dbus/, device/.avi@chromium.org2013-06-111-1/+1
| | | | | | | | | | BUG=247723 TEST=none TBR=ben@chromium.org Review URL: https://chromiumcodereview.appspot.com/16123026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205457 0039d316-1c4b-4281-b951-d872f2087c98
* Add RSAPrivateKey::CreateFromKeypair()cmasone@chromium.org2013-05-081-0/+16
| | | | | | | | | | | Add a static method to create an RSAPrivateKey object from an NSS public/private keypair. Only declared and implemented when USE_NSS is defined. BUG=235179 Review URL: https://chromiumcodereview.appspot.com/14941007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@198985 0039d316-1c4b-4281-b951-d872f2087c98
* Implement RSAPrivateKey::Copy()sergeyu@chromium.org2011-12-031-2/+8
| | | | | | | | BUG=105220 Review URL: http://codereview.chromium.org/8727014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@112837 0039d316-1c4b-4281-b951-d872f2087c98
* RSAPrivateKey vector push_back cleanups.mattm@chromium.org2011-11-151-3/+1
| | | | | | | | | | BUG=none TEST=unittests Review URL: http://codereview.chromium.org/8533028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@110043 0039d316-1c4b-4281-b951-d872f2087c98
* Search all slots when looking for a key in NSSgspencer@google.com2011-06-081-22/+14
| | | | | | | | | | | This should make it possible to run on a VM, and still find the private key created for the owner in the software slot. BUG=chromium-os:15817 TEST=Built an image and tried it on a VM and a device. Both showed restricted users list. Review URL: http://codereview.chromium.org/7066070 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@88380 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing FindFromPublicKeyInfo so that it searches the "Public" NSS databasegspencer@google.com2011-05-251-29/+35
| | | | | | | | | | | | | | | | | | if it doesn't find the requested key in the "Private" NSS database. This fixes the ownership process because the ownership key is created in the public database because that needs to happen before the TPM is owned and available (and it's not really all that sensitive to begin with). BUG=chromium-os:15645 TEST=Built a new recovery image, wiped a device with it and verified that I was able to sign in as a new user and add users and forget networks. It also showed me as the owner of the device. Review URL: http://codereview.chromium.org/7066032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@86654 0039d316-1c4b-4281-b951-d872f2087c98
* This adds calls to new API for cryptohomed that gives statusgspencer@chromium.org2011-04-191-3/+4
| | | | | | | | | | | | | | of the PKCS#11 initialization of the TPM. Also, add cros_library wrapper calls for new libcros API. BUG=chromium-os:12303 TEST=Ran on device, checked to make sure TPM certs showed up, indicating that status and user PIN were successfully retrieved. Review URL: http://codereview.chromium.org/6838032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@82134 0039d316-1c4b-4281-b951-d872f2087c98
* Move crypto files out of base, to a top level directory.rvargas@google.com2011-04-141-0/+248
src/crypto is now an independent project that contains our cryptographic primitives (except md5 and sha1). This removes the base dependency from nss, openssl and sqlite. BUG=76996 TEST=none Review URL: http://codereview.chromium.org/6805019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@81611 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-19 16:57:12 +0000