| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
r=nss-reviewers,djackson
Depends on D36757
Differential Revision: https://phabricator.services.mozilla.com/D37215
|
| |
|
|
|
|
|
|
|
|
| |
r=nss-reviewers,djackson
Some of our dynamic template choosers, e.g. sec_pkcs12_choose_attr_type, can
return NULL. This patch adds some defensive checks to avoid crashes when
they do.
Differential Revision: https://phabricator.services.mozilla.com/D150290
|
| |
|
|
|
|
| |
r=nss-reviewers,djackson
Differential Revision: https://phabricator.services.mozilla.com/D148413
|
| |
|
|
|
|
|
|
|
|
| |
r=kjacobs,rrelyea
Previously we only used the "object" attribute (mapped to CKA_LABEL) to find certificates by PKCS #11 URI. This updates the logic to match also with "id" (mapped to CKA_ID) and reject the request if a "type" attribute is present with the value other than "cert".
Note: as "id" may not be null-terminated, the PKCS #11 URI API had to be revamped to allow binary blobs. This is still not perfect because PK11URIAttribute doesn't have a length field of value.
Differential Revision: https://phabricator.services.mozilla.com/D98940
|
| | |
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D149931
|
| | |
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D149592
|
| | |
|
| |
|
|
|
|
| |
certificate verifier. r=rrelyea
Differential Revision: https://phabricator.services.mozilla.com/D148414
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GROUP. r=keeler,nss-reviewers,djackson
In an iteration over elements of an indefinite-length encoded GROUP
(sec_asn1d_next_in_group), the child of the current state is responsible for
parsing the GROUP's end-of-contents octets---a call to
sec_asn1d_parse_end_of_contents(state->child) sets the endofcontents flag for
state->child and a later call to sec_asn1d_next_in_group checks
state->child->endofcontents and terminates the iteration.
In an iteration over elements of an indefinite-length encoded SEQUENCE
(sec_asn1d_next_in_sequence), on the other hand, the current state, not its
child, handles the end-of-contents octets.
Prior to this commit, an error would occur when state pointed to an
indefinite-length encoded GROUP and state->child pointed to an
indefinite-length encoded SEQUENCE. In this case, state->child would be passed
to sec_asn1d_parse_end_of_contents to parse the SEQUENCE's end-of-contents
octets. This would set the endofcontents flag for state->child, and this would
be misinterpreted as an end-of-iteration signal for the surrounding GROUP.
Differential Revision: https://phabricator.services.mozilla.com/D142985
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D137702
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `stateEnd->parent != state` check was added in Bug 95458 to avoid a crash
in `sec_asn1d_free_child`. The diagnosis in Bug 95458 is incorrect---the crash
was actually due to a `PORT_Assert(0)` that was meant to highlight a memory
leak when `SEC_ASN1DecoderStart` was called with `their_pool==NULL`. The
offending assertion was removed in Bug 95311, which makes the `stateEnd` check
obsolete. In Bug 1753535 it was observed that the `stateEnd` check could read
from a poisoned region of an arena when the decoder was used in a streaming
mode. This read-after-poison could lead to an arena memory leak, although this
is mitigated by the fact that the read-after-poison is on an error-handling path
where the caller typically frees the entire arena.
Differential Revision: https://phabricator.services.mozilla.com/D140861
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. This patch adds a new command, validation, which dumps the validation
objects ina given token. It defaults to the softoken.
2. It sets up the infrastructure to allow creation at init time of token
specific objects (like validation objects and profile objects) by:
2a. factoring out the code to get the next available object handle to a
new function call sftk_getNextHandle().
2b. The object freelists are now initialized before SFTK_SlotInit, so that
SFTK_SlotInit can initialize these new token objects.
2c. A new staticly defined session is created to hand these object on.
2c1. sftk_NewSession and sftk_FreeSession has the initialization and
clearing functions factored out from the actual space freeing clearing
so they can be used on this staticly allocated session. (NOTE: NSS has
two ways it handles this internally: use of Init/New Clear/Free
functions as in this patch, or the use of a bool called 'FreeIt' added
to the original function. There is no technical reason for why I used
Init/New other than I didn't have to go change all the places the
currently call them. These are internal private functions, so it's ok
to change their signatures.
2c2. The static sessions are initialized on freed when the slot is
created and destroyed.
3. For fips slot the validation object is created. The version number is
selected at compile time with a build time environment variable. If no
version number is provided, a default version number (related to the NSS
version) is selected as well as the string 'unvalidated'.
4. The NSS spefic defines for Validation objects are defined in the NSS vendor
space (until PKCS #11 v3.2 comes out with the official values).
Differential Revision: https://phabricator.services.mozilla.com/D124951
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D122743
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This validates that they are LDH (with underscore because we don't hate
freedom), but that they are not IP addresses. This invokes the horrible WhatWG
IP parsing routines, so that it recognizes a vast array of crazy address formats
(thanks 1980s design).
Differential Revision: https://phabricator.services.mozilla.com/D116343
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes from the review:
The while loop was taken out of it's subshell pipe, which prevented the selfserv PID from being passed on to the final selfserv-kill. This eventally lead to a freeze on windows.
The last paragraph of ISO 19790:2012 section 7.2.4.2 states:
All services shall [02.24] provide an indicator when the service utilises an approved cryptographic algorithm, security function or process in an approved manner and those services or processes specified in 7.4.3
This means our libraries need to grow an API or provide some additional information via contexts or similar in order for an application to be able to query this indicator. This can't be just a Security Policy description because ISO 24759:2017 section 6.2.4.2 states:
TE02.24.02: The tester shall execute all services and verify that the indicator provides an unambiguous indication of whether the service utilizes an approved cryptographic algorithm, security function or process in an approved manner or not.
The indicator can't be just a marker over an algorithm either, because it needs to show different values based on whether the algorithm parameters causes the algorithm to run in approved or non-approved mode (ie keys outside of valid range for RSA means RSA is being used in non-approved mode ...)
For NSS, there is a PKCS #11 design:
https://docs.google.com/document/d/1Me9YksPE7K1Suvk9Ls5PqJXPpDmpAboLsrq0z54m_tA/edit?usp=sharing
This patch implments the above design as well as:
1) NSS proper functions to access these indicators from either the pk11wrap layer or the ssl layer.
2) Updates to the ssl tests which will output the value of the
Changes decription by file:
cmd/selfserv/selfserv.c
Add a FIPS indicator if the connection was excuted in FIPS mode on a FIPS token.
cmd/strsclnt/strsclnt.c
Add a FIPS indicator if the connection was excuted in FIPS mode on a FIPS token.
cmd/tstclnt/tstclnt.c
Add a FIPS indicator if the connection was excuted in FIPS mode on a FIPS token.
lib/nss/nss.def
Add the new pk11 functions to access the fips indicator.
lib/pk11wrap/pk11cxt.c
Implement a function to get the FIPS indicator for the current PK11Context.
lib/pk11wrap/pk11load.c
Get the fips indicator function from the PKCS #11 module using the vendor function interface from PKCS #11 v3.0
lib/pk11wrap/pk11obj.c
Implement a function to get the FIPS indicator for a specific PKCS #11 object.
lib/pk11wrap/pk11priv.h
Add a generalized helper function to get the FIPS indicator used by all the other exported functions to get FIPS indicator.
lib/pk11wrap/pk11pub.h
Add function to get the FIPS indicator for the current PK11Context.
lib/pk11wrap/pk11slot.c
Implement a generalized helper function to get the FIPS indicator.
Implement a function to get the FIPS indicator for the latest single shot operation on the slot.
lib/pk11wrap/secmodt.h
Add a new field to hold the fipsIndicator function.
lib/softoken/fips_algorithms.h
New sample header which vendors can replace with their own table. In the default NSS case, the table in this header will be empty.
lib/softoken/fipstokn.c
Add Vendor specific interface for the FIPS indicator to the FIPS token.
lib/softoken/pkcs11.c
Add Vendor specific interface for the FIPS indicator to the non-FIPS token.
Factor out the code tha maps an attribute value to a mechanism flag to it's own file so it can
be used by other parts of softoken. (new function is in pkcs11u.c
Implement the function that returns the FIPS indicator. This function fetches the indicator from either the session or the object or both. The session indicator is in the crypto context (except the last operation indicator, which is in the session itself. The object indicator is in the base object.
lib/softoken/pkcs11c.c
Record the FIPS indicator in the various helper function.
- sftk_TerminateOp is called when a crypto operation had been finalized, so we can store that fips indicator in the lastOpWasFIPS field.
- sftk_InitGeneric is called when a crypto operation has been initialized, so we can make a preliminary determination if the operation is within the FIPS policy (could later change bases on other operations. For this to work, we need the actual mechanism, so pMechanism is now a parameter to sftk_InitGeneric.
- sftk_HKDF - HKDF when used in TLS has the unusual characteristic that the salt could actually be a key. In this case, usually the base key is some known public value which would not be FIPS generated, but the security is based on whether the salt is really a FIPS generated key. In this case we redo the calculation based on the salt key.
lib/softoken/pkcs11i.h
- add the FIPS indicators to the various structures (crypto contexts, sessions, objects).
- add the FIPS indicators function list
- add pMechanism the the sftkInitGeneric function.
- add the helper function to map Attribute Types to Mechanism Flags.
- add the function that will look up the current operation in the FIPS table to determine that it is allowed by policy.
lib/softoken/pkcs11u.c
- include the new fips_algorithms.h (if NSS_FIPS_DISABLED is not on)
- handle the FIPS status for objects and session on creation an copy.
- implement the helper function to map Attribute Types to Mechanism Flags.
- get the key length of a key. This involves getting the key type and then using the key type to determin the appropriate attribute to fetch. Most keys it's simply the CKA_VALUE. ECC is special, we get the key length from the curve. Since only a subset of curves can be FIPS Curves, we use key length to return false for other curves.
- the handle special function handles any unusal semantics for various mechanism types. This function precodes possible mechanism semantics we may need to check. The special handling can be selected by the mechanism table in fips_algorithms.h
- sftk_operationIsFIPS - the actual function to determine if the givelib/n operation is in the FIPS table.
lib/softoken/sftkmessage.c
- just need to update the sftk_InitGeneric function to pass the mechanism.
lib/ssl/ssl3con.c
- and functions to query the underlying crypto contexts to see if the current ssl session is running in FIPS approved mode based on the security policy. It does so by checking the CipherSpecIsFIPS function to verify that both the mac and the encryption algorithm FIPS conforms to the ciphers in the security profile (using PK11_GetFIPSStatus). We check both the cipher specs for read and write. These underlying specs depends on the keys used in these specs being generated with FIPS approved algorithms as well, so this verifies the kea and kdf functions as well.
lib/ssl/sslimpl.h
- ass ssl_isFIPS() so it can be used by other files here in the ssl directory.
lib/ssl/sslinfo.c
- set the new isFIPS field in the existing sslinfo structure. SSL_GetChannelInfo knows how to handle sslinfo structures that are smaller then expected and larger than expected. unknown fields will be set to '0' (so new applications running against old versions will always get zero for new fields). sslinfo that are smaller will only return a the subset the calling application expects (so old applications will not get the new fields).
lib/ssl/sslt.h
- Add the new isFIPS field (must be at the end of the ChannelInfo structure).
lib/util/pkcs11n.h
- add the new FIPS indicator defines.
tests/ssl/ssl.h
- The main changes was to turn on verbose for the coverage tests so we can test the FIPS indicators on various cipher suites. NOTE: this only works with either NSS_TEST_FIPS_ALGORIHTMS set, or a vendor fips_algorthims.h, so vendors will need to do their own test interpretation. While working in ssl.sh I fixed an number of other issues:
- many tests that were skipped in FIPS mode were skipped not because they didn't work in FIPS mode, but because tstclnt requires a password when running in FIPS mode. I've now added the password if the function is running in fips mode and removed the fips restrictions.
- dtls had a race condition. the server side needed to come up before the client, but couldn't end before the client ran. We already had a sleep to guarrentee the former, I added a sleep before sending the server it's data to handle the latter.
- CURVE25519 is the default ECC curve, but it's not a fiPS curve, so I disable it in FIPS mode so we will actually get FIPS indicators when using ECDHE.
- I added TLS 1.3 to the coverage tests.
Differential Revision: https://phabricator.services.mozilla.com/D115034
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also fixes:
Bug 452464 pk12util -o fails when -C option specifies AES or Camellia ciphers
Related:
Bug 1694689 Firefox should use modern algorithms in PKCS#12 files by default
Bug 452471 pk12util -o fails when -c option specifies pkcs12v2 PBE ciphers
The base of this fix is was a simple 3 line fix in pkcs12.c, changing the initial setting of cipher and cert cipher.
Overview for why this patch is larger than just 3 lines:
1. First issue was found in trying to change the mac hashing value.
a. While the decrypt side knew how to handle SHA2 hashes, the equivalent code was not updated on the encrypt side. I refactored that code and placed the common function in p12local.c. Now p12e.c and p12d.c share common code to find the required function to produce the mac key.
b. The prf hmac was hard coded to SHA1. I changed the code to pass the hmac matching the hashing algorithm for the mac. This required changes to p12e.c to calculate and pass the new hmac as well and adding new PK11_ExportEncryptedPrivateKey and PK11_ExportEncryptedPrivKey to take the PKCS #5 v2 parameters. I also corrected an error which prevented pkcs12 encoding of ciphers other than AES.
2. Once I've made my changes, I realized we didn't have a way of testing them. While we had code that verified that particular sets of parameters for pkcs12 worked together and could be listed and imported, we didn't have a way to verify what algorithms were actually generated by our tools.
a. pk12util -l doesn't list the encryption used for the certs, so I updated pp to take a pkcs12 option. In doing so I had to update pp to handle indefinite encoding when decoding blocks. I also factored that decoding out in it's own function so the change only needed to be placed once. Finally I renabled a function which prints the output of an EncryptedPrivate key. This function was disabled long ago when the Encrypted Private key info was made private for NSS. It has since been exported, so these functions could easily be enabled (archeological note: I verified that this disabling was not a recent think I found I had done it back when I still have a netscape email address;).
b. I updated tools.sh to us the new pp -t pkcs12 feature to verify that the key encryption, cert encryption, and hash functions matched what we expected when we exported a new key. I also updated tools.sh to handle the new hash variable option to pk12util.
c. I discovered several tests commented out with comments that the don't work. I enabled those tests and discovered that they can now encrypt, but the can't decrypt because of pkcs12 policy. I updated the policy code, but I updated it to use the new NSS system wide policy mechanism. This enabled all the ciphers to work. There is still policy work to do. The pk12 policy currently only prevents ciphers from use in decrypting the certificates, not decrypting the keys and not encrypting. I left that for future work.
3. New options for pp and pk12util were added to the man pages for these tools.
---------------------------------------------------------------------------
With that in mind, here's a file by file description of the patch:
automation/abi-check/expected-report-libnss3.so.txt
-Add new exported functions. (see lib/nss/nss.def)
cmd/lib/basicutil.h:
-Removed the HAVE_EPV_TEMPLATE ifdefs (NSS has exported the Encrypted Private Key data structure for a while now.
cmd/lib/secutil.c:
global: Updated several functions to take a const char * m (message) rather than a char * m
global: Made the various PrintPKCS7 return an error code.
global: Added a state variable to be passed around the various PKCS7 Print functions. It gives the proper context to interpret PKCS7 Data Content. PKCS 12 used PKCS7 to package the various PKCS12 Safes and Bags.
-Updated SECU_StripTagAndLength to handle indefinite encoding, and to set the Error code.
-Added SECU_ExtractDERAndStep to grab the next DER Tag, Length, and Data.
-Updated secu_PrintRawStringQuotesOptional to remove the inline DER parsing and use SECU_ExtractDERAndStep().
-Updated SECU_PrintEncodedObjectID to return the SECOidTag just like SECU_PrintObjectID.
-Renable SECU_PrintPrivateKey
-Added secu_PrintPKCS12Attributes to print out the Attributes tied to a PKCS #12 Bag
-Added secu_PrintPKCS12Bag to print out a PKCS #12 Bag
-Added secu_PrintPKCS7Data, which uses the state to determine what it was printing out.
-Added secu_PrintDERPKCS7ContentInfo which is identical to the global function SECU_PrintPKCS7ContentInfo except it takes a state variable. The latter function now calls the former.
-Added secu_PrintPKCS12DigestInfo to print the Hash information of the Mac. DigestInfo is the name in the PKCS 12 spec.
-Added secu_PrintPKCS12MacData to print the Mac portion of the PKCS 12 file.
-Added SECU_PrintPKCS12 to print otu the pkcs12 file.
cmd/lib/secutil.h
-Added string for pkc12 for the command line of pp
reenabled SECU_PrintPrivateKey
-Added SECU_PrintPKCS12 for export.
cmd/pk12util/pk12util.c
-Added the -M option to specify a hash algorithm for the mac.
updated P12U_ExportPKCS12Object: pass the hash algorithm to the PasswordIntegrity handler.
-Added PKCS12U_FindTagFromString: generalized string to SECOidTag which only filters based on the oid having a matching PKCS #11 mechanism.
updated PKCS12U_MapCipherFromString to call use PKCS12U_FindTagFromString to get the candidate tag before doing it's post processing to decide if the tag is really an encryption algorithm.
-Added PKCS12U_MapHashFromString with is like MapCipherFromString except it verifies the resulting tag is a hash object.
-Updated main to 1) change the default cipher, change the default certCipher, and process the new hash argument. NOTE: in the old code we did not encrypt the certs in FIPS mode. That's because the certs were encrypted with RC4 in the default pkcs12 file, which wasn't a FIPS algorithm. Since AES is, we can use it independent on whether or not we are in FIPS mode.
cmd/pp/pp.c
-Added the pkcs12 option which calls SECU_PrintPKCS12 from secutil.c
lib/nss/nss.def
-Add exports to the new PK11_ExportEncryptedPrivKeyInfoV2 and PK11_ExportEncryptedPrivateKeyInfoV2 (V2 means PKCS 5 v2, not Version 2 of ExportEncrypted*Info).
-Add export for the old HASH_GetHMACOidTagByHashOidTag which should have been exported long ago to avoid the proliferation of copies of this function in places like ssl.
lib/pk11wrap/pk11akey.c
-Add PK11_ExportEncryptedPrivKeyInfoV2 (which the old function now calls), which takes the 3 PKCS 5 v2 parameters. The underlying pkcs5 code can fill in missing tags if necessary, but supplying all three gives the caller full control of the underlying pkcs5 PBE used.
-Add PK11_ExportEncryptedPrivateKeyInfoV2, same as the above function except it takes a cert which is used to look up the private key. It's the function that pkcs12 actually uses, but the former was exported for completeness.
lib/pk11wrap/pk11pub.h
-Added the new PK11_ExportEncryptedPriv*KeyInfoV2 functions.
lib/pkcs12/p12d.c
-Remove the switch statement and place it in p12local.c so that p12e.c can use the same function.
lib/pkc12/p12e.c
-Remove the unnecessary privAlg check so we can encode any mechanism we support. This only prevented encoding certificates in the pk12 file, not the keys.
-add code to get the hmac used in the pbe prf from the integrity hash, which is under application control.
-Do the same for key encryption, then use the new PK11_ExportEncryptedPrivateKeyInfo to pass that hash value.
-Use the new sec_pkcs12_algtag_to_keygen_mech so there is only one switch statement to update rather than 2.
-Update the hash data to old the length of the largest hash rather than the length of a SHA1 hash.
lib/pkcs12/p12local.c
- Add new function new sec_pkcs12_algtag_to_keygen_mech to factor out the common switch statement between p12e and p12d.
lib/pkcs12/p12local.h
-Export the new sec_pkcs12_algtag_to_keygen_mech
lib/pkcs12/p12plcy.c
-Map the old p12 policy functions to use the new NSS_GetAlgorithmPolicy. We keep the old table so that applications can change the policy with the old PKCS12 specific defines (so the old code keeps working). NOTE: policies now default to true rather than false.
lib/util/secoidt.h
-Add new NSS_USE_ALG_IN_PKCS12 used by pk11plcy.c
NOTE: I have not updated the policy table in pk11wrap/pk11pars.c, so we can't yet control pkcs12 policy with the nss system policy table. That's a patch for another time.
test/tools/tool.sh
-global: Remove trailing spaces
-global: DEFAULT is changed to 'default'
-Update the PBE mechanism to exactly match the string in secoid.c. PKCS #12 does case independent compares, so case doesn't matter there, but now I'm comparing to the output of pp, and I didn't want to spend the time to figure out case independent compares in bash.
-Add our defauts and shell variables at the top so there are easy to change in the future.
export_with_*** have all been colapsed into a single export_p12_file which handles taking 'default' and turning off that argument.
-Add for loops for the hash functions.
-Restore the camellia ciphers back now that they work.
-Restore the pkcs12V2pbe back now that they work.
-Collect various pbe types into single variables and use those variables in loops
-Reduce the number of tests ran in optimized mode (which takes 60x the time to do a pbe then than debug mode based on a larger iterator).
-Add verify_p12 which dumps out the p12 file and makes sure the expected CERT_ENCRYPTION, KEY_ENCRYPTION, and HASH are used.
doc/pp.xml
-Add pkcs12 option
doc/pk12util.xml
-Add -M option
-Update synopsis with options in the description but not in the synopsis
Differential Revision: https://phabricator.services.mozilla.com/D113699
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FIPS 180-3 updated the standard for clearing sensitive key material in FIPS modules. I've done a complete review of the portions of NSS affected by the FIPS requirements and identified all the areas where we need to update. The report is available here: https://docs.google.com/document/d/1v9kedUiwVYYIUagyT_vQdtrktjGUrA3SFsVP-LA6vOw/edit?usp=sharing
This patch does the following:
- Clears the stack in gcm and ecc to deal with large stack leakages.
This only happens in FIPS enabled case. The size of the stack is based on the
size of the leakage, with some extra to make sure we reach down into that area.
Most of the leakage happens in either auto generated code or machine dependent
acceleration code.
- Clears hash related data that wasn't cleared previously
- Clears public key exponents that wasn't cleared previously.
- Clears components that should have been cleared previously but wasn't.
Usually clearing takes one of the following forms:
PORT_Free(x) -> PORT_Free(x, size). This means we need to know what
the size is supposed to be. In some cases we need to add code to preserve
the size.
PORT_Free(x.data) -> SECITEM_ZfreeItem(&x, PR_FALSE). In this case x is
a SECITEM, which carries the length. PR_FALSE means clear and free the data in
the item, not the item itself. The code should have had SECITEM_FreeItem before
anyway.
SECIEM_FreeItem(item, bool) -> SECITEM_ZfreeItem(item, bool). Simply change
the normal SECITEM free call to the one that clears the item.
PR_ArenaFree(arena, PR_FALSE) -> PR_ArenaFree(arena, PR_TRUE). The bool here
means whether or not to clear as well as free the data in the arena.
PORT_Memset(value, 0, size). This the obvious clear operation. It happens
if the variable is a stack variable, or if the memory isn't cleared with one
of the three clearing functions above.
In addition this patch fixes the following:
- moves the determination if whether or not a slot is in FIPS mode by
slotID to a macro. NSS allows user defined slots to be opened. If you open a
user defined slot using the FIPS slot, the resulting slots will also be FIPS
slots. In areas where the semantics change based on the slot, these slots should
have the FIPS semantics. Directly checking if the slot is the FIPS slot now
only happens when we really mean the main FIPS slot and not just any FIPS slot.
- In handling the clearing of PSS and OAEP, I identified an issue. These
functions where holding a pointer to the pMechanismParams in their C_XXXXInit
calls for later use in the C_XXXXUpdate/C_XXXXFinal/C_XXXX calls. The problem
is applications are allowed to free their pMechanismParams once C_XXXXInit is
complete. We need to make a copy of the params to use them.
Differential Revision: https://phabricator.services.mozilla.com/D108223
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D112226
|
| | |
|
| |
|
|
|
|
| |
Depends on D104418
Differential Revision: https://phabricator.services.mozilla.com/D106144
|
| |
|
|
|
|
| |
build. r=rrelyea
Differential Revision: https://phabricator.services.mozilla.com/D104418
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
PKCS#11 v2.40:
https://www.cryptsoft.com/pkcs11doc/STANDARD/include/v240/pkcs11t.h line 1150
jdk8u:
https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/eb7f437285a1/src/share/native/sun/security/pkcs11/wrapper/pkcs11t.h#l1155
Differential Revision: https://phabricator.services.mozilla.com/D97337
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
support
Policy update
Current state of the nss policy system:
The initial policy patch focused on getting policy working well in handling ssl. The policy infrastructure used two existing NSS infrastructure:
1) Algorithm policies tied the OIDS and
2) the ssl policy constraints first created to handle export policy restrictions.
To make loadable policies work, we added a couple of new things:
1) a policy parser to the secmod infrastructure which allows us to set algorithm policies based on a config file. This file had two sections: disallow= and allow=. Disallow turned off policy bits, and allow turned them on. Disallow was always parsed first, so you could very strictly control your policy map by saying disallow=all allow={exclusive list of allowed algorithms}
2) a new NSS_Option() value that allowed the policy parser to set integer values (like minimum tls version) based on the data in the policy parser.
3) SSL code which is run at ssl_init time that reads the algorithm policies and maps the results to SSL policies.
The resulting loaded policy code, in general, sets the boundaries of what it possible, actually enable/disable of ssl cipher suites are still under program control, and the builtin NSS default values. The only consession to configuration is if a cipher is disallowed by policy, it is also disabled. Allowing a cipher suite by policy that wasn't already enabled, however, doesn't enable that policy by default. Inside the policy restrictions, applications can still make their own decisions on configuration and preference.
At the time the policy system was designed, there were 3 additional features, which were designed, but not specified: disable, enable, and lock.
disable and enable work just like disallow and allow, except the specify what the default settings are. This would allow the policy file to change the underlying default in the case where the application doesn't try to configure ssl on it's own.
lock would make either the policy or configuration 'locked' meaning once the lock has been executed, no further changes to those configurations would be allowed.
What is needed:
We have a need for the following additional features:
1) we want to turn more of the sha-1 hash function off by default. We still need sha-1 digest because it's used in many non-secure cases, but we do want to disable more sha-1 signature usage. Currently only CERT-SIGNATURE and various hmac usages in SSL ciphers can be controlled by policy. We want to disallow a greater range of signature (that is signature use in general).
2) we want to disable more ciphers by default, but need a way to have certain policies (like LEGACY) turn them back on, so that our shipped system is more secure by default.
What this patch provides:
1) A new policy flag NSS_USE_ALG_IN_ANY_SIGNATURE was added. The cryptohi code which exports the NSS sign/verify high level code now checks the hash and signing algorithm against this new policy flag and fails if the policy isn't available.
New key words were added to the policy parser for 'all-signature', which implies all signature flags at once, and 'signature', which maps to NSS_USE_ANY_SIGNATURE. NOTE: disable=all/signature and disable=all/all-signature are effective equivalent because cert-signatures eventually call the low level signature functions, but disable=all allow=rsa-pss/all-signature and disable=all allow=rsa-pss/signature are different in that the latter allows all rsa-pss signature and the latter allows rsa-pss signatures, but no on certificates (or on smime in the future)
Also new keywords were added for rsa-pkcs, rsa-pss, and ecdsa for signature algorithms (along with dsa).
2) This patch implements disable and enable. These functions only work on SSL configuration. In the future SMIME/CMS configuration could also be added. Because the policy system is parsed and handled by NSS, and SSL configuration is handled in SSL, we use the same Apply code we used to apply ssl policy to set the inital configuration. The configured enable/disable state is configured in the ALGORTHIM policy system, where one bit says the enable/disable value is active and another bit which gives it's state.
3) two locks have been implented, policy-lock and ssl-lock. These are specified in the parser as flags (flags=policy-lock,ssl-lock). The policy locks all the policy changes: ssl_policy, algorithm policy, and options. It is implemented by two new exported functions: NSS_IsPolicyLocked() and NSS_LockPolicy(). The first allows applications to test if the policy is locked without having to try changing the policy. The various policy set functions check the NSS_IsPolicyLocked() function and returns SEC_ERROR_POLICY_LOCK if it's true.
The ssl-lock changes the state of the policy to locked, and the state cannot be changed back without shutting down NSS. The second is implemented by setting a new Option called NSS_DEFAULT_LOCKS and the NSS_DEFAULT_SSL_LOCK flag. The idea is we can add an SMIME lock in the future. SSL checks the NSS_DEFAULT_SSL_LOCK flag before trying to set the cipher suite value, and blocks the change if it's set.
4) sslpolicy tests were updated to test the enable, disable, flags=policy-lock, flags=ssl-lock and the new signature primitives.
5) policy tests were updated to be able to run standalone (like all the other all.sh tests), as well as new tests to detect when no signing algorithms have been enabled.
What is not in the patch
1) S/MIME signature policy has been defined for a while, but never hooked up.
2) S/MIME export policy needs to be connected back to the algorithm policy system just like the ssl cipher suites already are.
3) S/MIME default configuration needs to be connected back to the policy system.
4) ECC Curve policy needs to be hooked up with the signature policy (probably should create a generic 'key meets policy' function and have every call it).
Differential Revision: https://phabricator.services.mozilla.com/D93697
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
support
Policy update
Current state of the nss policy system:
The initial policy patch focused on getting policy working well in handling ssl. The policy infrastructure used two existing NSS infrastructure:
1) Algorithm policies tied the OIDS and
2) the ssl policy constraints first created to handle export policy restrictions.
To make loadable policies work, we added a couple of new things:
1) a policy parser to the secmod infrastructure which allows us to set algorithm policies based on a config file. This file had two sections: disallow= and allow=. Disallow turned off policy bits, and allow turned them on. Disallow was always parsed first, so you could very strictly control your policy map by saying disallow=all allow={exclusive list of allowed algorithms}
2) a new NSS_Option() value that allowed the policy parser to set integer values (like minimum tls version) based on the data in the policy parser.
3) SSL code which is run at ssl_init time that reads the algorithm policies and maps the results to SSL policies.
The resulting loaded policy code, in general, sets the boundaries of what it possible, actually enable/disable of ssl cipher suites are still under program control, and the builtin NSS default values. The only consession to configuration is if a cipher is disallowed by policy, it is also disabled. Allowing a cipher suite by policy that wasn't already enabled, however, doesn't enable that policy by default. Inside the policy restrictions, applications can still make their own decisions on configuration and preference.
At the time the policy system was designed, there were 3 additional features, which were designed, but not specified: disable, enable, and lock.
disable and enable work just like disallow and allow, except the specify what the default settings are. This would allow the policy file to change the underlying default in the case where the application doesn't try to configure ssl on it's own.
lock would make either the policy or configuration 'locked' meaning once the lock has been executed, no further changes to those configurations would be allowed.
What is needed:
We have a need for the following additional features:
1) we want to turn more of the sha-1 hash function off by default. We still need sha-1 digest because it's used in many non-secure cases, but we do want to disable more sha-1 signature usage. Currently only CERT-SIGNATURE and various hmac usages in SSL ciphers can be controlled by policy. We want to disallow a greater range of signature (that is signature use in general).
2) we want to disable more ciphers by default, but need a way to have certain policies (like LEGACY) turn them back on, so that our shipped system is more secure by default.
What this patch provides:
1) A new policy flag NSS_USE_ALG_IN_ANY_SIGNATURE was added. The cryptohi code which exports the NSS sign/verify high level code now checks the hash and signing algorithm against this new policy flag and fails if the policy isn't available.
New key words were added to the policy parser for 'all-signature', which implies all signature flags at once, and 'signature', which maps to NSS_USE_ANY_SIGNATURE. NOTE: disable=all/signature and disable=all/all-signature are effective equivalent because cert-signatures eventually call the low level signature functions, but disable=all allow=rsa-pss/all-signature and disable=all allow=rsa-pss/signature are different in that the latter allows all rsa-pss signature and the latter allows rsa-pss signatures, but no on certificates (or on smime in the future)
Also new keywords were added for rsa-pkcs, rsa-pss, and ecdsa for signature algorithms (along with dsa).
2) This patch implements disable and enable. These functions only work on SSL configuration. In the future SMIME/CMS configuration could also be added. Because the policy system is parsed and handled by NSS, and SSL configuration is handled in SSL, we use the same Apply code we used to apply ssl policy to set the inital configuration. The configured enable/disable state is configured in the ALGORTHIM policy system, where one bit says the enable/disable value is active and another bit which gives it's state.
3) two locks have been implented, policy-lock and ssl-lock. These are specified in the parser as flags (flags=policy-lock,ssl-lock). The policy locks all the policy changes: ssl_policy, algorithm policy, and options. It is implemented by two new exported functions: NSS_IsPolicyLocked() and NSS_LockPolicy(). The first allows applications to test if the policy is locked without having to try changing the policy. The various policy set functions check the NSS_IsPolicyLocked() function and returns SEC_ERROR_POLICY_LOCK if it's true.
The ssl-lock changes the state of the policy to locked, and the state cannot be changed back without shutting down NSS. The second is implemented by setting a new Option called NSS_DEFAULT_LOCKS and the NSS_DEFAULT_SSL_LOCK flag. The idea is we can add an SMIME lock in the future. SSL checks the NSS_DEFAULT_SSL_LOCK flag before trying to set the cipher suite value, and blocks the change if it's set.
4) sslpolicy tests were updated to test the enable, disable, flags=policy-lock, flags=ssl-lock and the new signature primitives.
5) policy tests were updated to be able to run standalone (like all the other all.sh tests), as well as new tests to detect when no signing algorithms have been enabled.
What is not in the patch
1) S/MIME signature policy has been defined for a while, but never hooked up.
2) S/MIME export policy needs to be connected back to the algorithm policy system just like the ssl cipher suites already are.
3) S/MIME default configuration needs to be connected back to the policy system.
4) ECC Curve policy needs to be hooked up with the signature policy (probably should create a generic 'key meets policy' function and have every call it).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=kjacobs
The streaming ASN.1 decoder had assertions that, on debug builds, blocked
embedding indefinite-length fields inside of definite-length fields/contexts,
however that behavior does work correctly, and is valid ASN.1: it tends to
happen when wrapping a signature around existing ASN.1-encoded data, if that
already-encoded data had an indefinite length.
Really these two assertion were just overzealous. The conditional after the
asserts handle the case well, and memory sanitizers have not found issue here
either.
Differential Revision: https://phabricator.services.mozilla.com/D93135
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
(draft-irtf-cfrg-hpke-05). r=mt
This patch adds support for Hybrid Public Key Encryption (draft-irtf-cfrg-hpke-05).
Because the draft number (and the eventual RFC number) is an input to the key schedule, future updates will *not* be backwards compatible in terms of key material or encryption/decryption. For this reason, a default compilation will produce stubs that simply return an "Invalid Algorithm" error. To opt into using the HPKE functionality , compile with `NSS_ENABLE_DRAFT_HPKE` defined. Once finalized, this flag will not be required to access the functions.
Lastly, the `DeriveKeyPair` API is not implemented as it adds complextiy around PKCS #11 and is unnecessary for ECH.
Differential Revision: https://phabricator.services.mozilla.com/D73947
|
