| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FIPS requires that we supply a hash and sign interface for our supported
signing algorithms to be validated. We already have those interfaces in
softoken for RSA PKCS1, DSA, and ECDSA. However, we don't test those
interfaces, now do we supply a way for an application to access those
interfaces (usually applications use the VFY_ and SGN_ interfaces which
handles the hashing an verify/sign operations).
We also have a generic pk11_signature_tests class in pk11_gtest, but only ecdsa
and some rsa pss tests uses it.
This patch rectifies all of these deficiencies:
lib/softokn
1) Hash and sign/verify mechanisms have been added to softoken to support PSS
hash and sign.
2) The rsa, dsa, and ecdsa hash and sign algorithms were also cleaned up by
creating a fake CKM_SHA1 which matches CKM_SHA_1 so that we can fully use the
same macros for all the hash types.
1&2 was sufficient to provide the goals of this task, however we wanted to be
able to add tests for this functionality..
lib/pk11wrap
3) Two new functions were added: PK11_CreateContextByPubKey and
PK11_CreateContextByPrivKey. These allow you to create multipart contexts with
Public and Private keys. This is a requirement to support hash and sign, as
they are multi-part operations (rather then just signing a hash, which is a
single part operation). With these functions, you can now use the PK11_DigestOp
and PK11_DigestFinal to complete a signature or verify optiation.
gtests/pk11_gtest
4) Add hash and sign/hash and verify support to the generic
pk11_signature_tests.h.
5) pk11_dsa_unittest.cc, pk11_rsa_unittest.cc, and the remainder of
pk11_rsapss_unittest.cc (Wycheproof tests) were moved to use the
pk11_signature_tests common implementation rather then their own.
6) pk11_ecdsa_unittest.cc was updated to support the hash&sign/verify combo
mechanism.
7) With multiple functions using pk11_signature_tests.h, The large functions
are moved to pk11_signature_tests.cpp.
8) The test vectors themselves were not changes, now just test against the
traditional hash first then verify interfaces and the hash and verify
interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D110641
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D112226
|
| | |
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D108638
|
| |
|
|
|
|
| |
c95ab70fcb2bc21025d8845281bc4bc8987ca683 r=beurdouche
Differential Revision: https://phabricator.services.mozilla.com/D107387
|
| | |
|
| |
|
|
|
|
| |
r=bbeurdouche
Differential Revision: https://phabricator.services.mozilla.com/D104067
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D103849
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch updates ECH implementation to draft-09. Changes of note are:
- Acceptance signal derivation is now based on the handshake secret.
- `config_id` hint changes from 32B to 8B, trial decryption added on the server.
- Duplicate code in HRR cookie handling has been consolidated into `tls13_HandleHrrCookie`.
- `ech_is_inner` extension is added, which causes a server to indicate ECH acceptance.
- Per the above, support signaling ECH acceptance when acting as a backend server in split-mode
(i.e. when there is no other local Encrypted Client Hello state).
Differential Revision: https://phabricator.services.mozilla.com/D101049
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds and exports two new HPKE functions: `PK11_HPKE_ExportContext` and
`PK11_HPKE_ImportContext`, which are used to export a serialized HPKE context,
then later reimport that context and resume Open and Export operations. Only receiver
contexts are currently supported for export (see the rationale in pk11pub.h).
One other change introduced here is that `PK11_HPKE_GetEncapPubKey` now works as
expected on the receiver side.
If the `wrapKey` argument is provided to the Export/Import functions, then the
symmetric keys are wrapped with AES Key Wrap with Padding (SP800-38F, 6.3)
prior to serialization.
Differential Revision: https://phabricator.services.mozilla.com/D99277
|
| | |
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D101648
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for Encrypted Client Hello (draft-ietf-tls-esni-08), replacing the existing ESNI (draft -02) support.
There are five new experimental functions to enable this:
- SSL_EncodeEchConfig: Generates an encoded (not BASE64) ECHConfig given a set of parameters.
- SSL_SetClientEchConfigs: Configures the provided ECHConfig to the given socket. When configured, an ephemeral HPKE keypair will be generated for the CH encryption.
- SSL_SetServerEchConfigs: Configures the provided ECHConfig and keypair to the socket. The keypair specified will be used for HPKE operations in order to decrypt encrypted Client Hellos as they are received.
- SSL_GetEchRetryConfigs: If ECH is rejected by the server and compatible retry_configs are provided, this API allows the application to extract those retry_configs for use in a new connection.
- SSL_EnableTls13GreaseEch: When enabled, non-ECH Client Hellos will have a "GREASE ECH" (i.e. fake) extension appended. GREASE ECH is disabled by default, as there are known compatibility issues that will be addressed in a subsequent draft.
The following ESNI experimental functions are deprecated by this update:
- SSL_EncodeESNIKeys
- SSL_EnableESNI
- SSL_SetESNIKeyPair
In order to be used, NSS must be compiled with `NSS_ENABLE_DRAFT_HPKE` defined.
Differential Revision: https://phabricator.services.mozilla.com/D86106
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Summary
This is useful for RSA-OAEP support.
The CKM_RSA_PKCS_OAEP mechanism requires a CK_RSA_PKCS_OAEP_PARAMS
be present for PKCS#11 calls. This provides required context for OAEP.
However, PK11_PubWrapSymKey lacks a way of providing this context and
historically silently converted CKM_RSA_PKCS_OAEP to CKM_RSA_PKCS when
a RSA key is provided. Introducing a new call will let us indicate
parameters and potentially support other mechanisms in the future.
This call mirrors the earlier calls introduced for RSA-PSS:
PK11_SignWithMechanism and PK11_VerifyWithMechanism.
The CKM_RSA_PKCS_OAEP mechanism requires a CK_RSA_PKCS_OAEP_PARAMS
be present for PKCS#11 calls. This provides required context for OAEP.
However, PK11_PubUnwrapSymKey lacks a way of providing this context,
and additionally lacked a way of indicating which mechanism type to use
for the unwrap operation (instead detecting it by key type). Introducing
a new call will let us indicate parameters and potentially support other
mechanisms in the future.
Signed-off-by: Alexander Scheel <ascheel@redhat.com>
Differential Revision: https://phabricator.services.mozilla.com/D93424
|
| | |
| |
| |
| |
| |
| | |
CERT_AddCertToListTailWithData. r=jcj
Differential Revision: https://phabricator.services.mozilla.com/D94524
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(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
|
| |/
|
|
|
|
|
|
|
|
|
| |
Actually, we have the implementation of ARM Crypto extension, so CI is always
run with this extension. It means that we don't run CI without ARM Crypto
extension. So I would like to add NoAES and NoSHA for aarch64 CI.
Also, we still run NoSSE4_1 on aarch64 CI, so we shouldn't run this on aarch64
hardware.
Differential Revision: https://phabricator.services.mozilla.com/D93062
|
| |
|
|
|
|
| |
This patch adds and exports `PK11_ImportDataKey`, and refactors the null PSK TLS 1.3 code to use it.
Differential Revision: https://phabricator.services.mozilla.com/D91316
|
| | |
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D90178
|
| | |
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D87322
|
| | |
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D84362
|
| |
|
|
|
|
|
|
| |
PK11_FindEncodedCertInSlot can be used to determine the PKCS#11 object handle
of an encoded certificate in a given slot. If the given certificate does not
exist in that slot, CK_INVALID_HANDLE is returned.
Differential Revision: https://phabricator.services.mozilla.com/D81924
|
| | |
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D80879
|
| |
|
|
|
|
|
|
|
|
| |
This patch adds support for External (out-of-band) PSKs in TLS 1.3. An External PSK (EPSK) can be set by calling `SSL_AddExternalPsk`, and removed with `SSL_RemoveExternalPsk`. `SSL_AddExternalPsk0Rtt` can be used to add a PSK while also specifying a suite and max_early_data_size for use with 0-RTT.
As part of handling PSKs more generically, the patch also changes how resumption PSKs are handled internally, so as to rely on the same mechanisms where possible.
A socket is currently limited to only one External PSK at a time. If the server doesn't find the same identity for the configured EPSK, it will fall back to certificate authentication.
Differential Revision: https://phabricator.services.mozilla.com/D56687
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This build can be tested by running
NSS_BUILD_MODULAR=1 nss/automation/taskcluster/scripts/build.sh
from a directory containing the nss and nspr repositories.
To make this build's make conditionals easier to handle, it also
merges the manifest.mn into the Makefile, because parts of the
conditionals depends on $(OS_ARCH) setting.
In the end, the goal is just to set the correct build $(DIRS).
This also drops the freebl dependeny of ssl, which seems not to be
needed, even if it's declared in /lib/ssl/ssl.gyp.
Differential Revision: https://phabricator.services.mozilla.com/D75074
|
| |
|
|
|
|
| |
Internally, NSS uses the system FIPS state to determine if it needs to go into FIPS mode independent of the database FIPS indication. Some applications need to know this value, particularly if the need to know the FIPS state before they call NSS_Init (NSS_IsFIPS() is only valid after init because it depends on the database indicator which is not known until NSS is intialized.
Differential Revision: https://phabricator.services.mozilla.com/D73986
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D74268
|
| |
|
|
|
|
| |
r=kjacobs
Differential Revision: https://phabricator.services.mozilla.com/D74211
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
that lack NSS database columns r=keeler,rrelyea
`sdb_GetAttributeValueNoLock` builds a query string from a list of attributes in the input template. Unfortunately, `sqlite3_prepare_v2` will fail the entire query if one of the attributes is missing from the underlying table. The PKCS #11 spec [[ https://www.cryptsoft.com/pkcs11doc/v220/pkcs11__all_8h.html#aC_GetAttributeValue | requires ]] setting the output `ulValueLen` field to -1 for such invalid attributes.
This patch reads and stores the columns of nssPublic/nssPrivate when opened, then filters an input template in `sdb_GetAttributeValueNoLock` for unbacked/invalid attributes, removing them from the query and setting their template output lengths to -1.
Differential Revision: https://phabricator.services.mozilla.com/D71622
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Part 2 of 2
Use the official PKCS #11 HKDF mechanism to implement tls 1.3.
1) The new mechanism is a single derive mechanism, so we no longer need to
pick it based on the underlying hmac (Note, we still need to know the
underlying hmac, which is passed in as a mechanism parameter).
2) Use the new keygen to generate CKK_HKDF keys rather than doing it by hand
with the random number generator (never was really the best way of doing this).
3) modify tls13hkdf.c to use the new mechanisms:
1) Extract: use the new key handle in the mechanism parameters to pass the
salt when the salt is a key handle.
Extract: use the explicit NULL salt parameter if for the hash len salt of
zeros.
2) Expand: Expand is mostly a helper function which takes a mechanism. For
regular expand, the mechanism is the normal _Derive, for the Raw version
its the _Data function. That creates a data object, which is extractable
in FIPS mode.
4) update slot handling in tls13hkdf.c:
1) we need to make sure that the key and the salt key are in the same
slot. Provide a PK11wrap function to make that guarrentee (and use that
function in PK11_WrapKey, which already has to do the same function).
2) When importing a 'data' key for the zero key case, make sure we import
into the salt key's slot. If there is no salt key, use PK11_GetBestSlot()
rather than PK11_GetInternal slot.
Differential Revision: https://phabricator.services.mozilla.com/D69899
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch 1 of 2.
This patch updates softoken and helper functions with the new PKCS #11 v3 HKDF,
which handles all the correct key management so that we can work in FIPS mode
1) Salts can be passed in as data, as and explicit NULL (which per spec means
a zero filled buffer of length of the underlying HMAC), or through a key handle
2) A Data object can be used as a key (explicitly allowed for this mechanism by
the spec).
3) A special mechansism produces a data object rather than a key, the latter
which can be exported. Softoken does not do the optional validation on the pInfo
to verify that the requested values are supposed to be data rather than keys.
Some other tokens may.
The old hkdf mechanism has been retained for compatibility (well namely until
patch 2 is created, tls is still using it). The hkdf function has been broken
off into it's own function rather than inline in the derive function.
Note: because the base key and/or the export key could really be a data object,
our explicit handling of sensitive and extractable are adjusted to take into
account that those flags do not exist in data objects.
Differential Revision: https://phabricator.services.mozilla.com/D68940
|
| |
|
|
|
|
| |
We already install these packages on the image_builder image itself. It seems they're now required on the fuzz32 image as well.
Differential Revision: https://phabricator.services.mozilla.com/D69274
|
| |
|
|
| |
r=me
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and ChaCha Poly
PKCS #11 defines a new interface for handling AEAD type ciphers that allow
multiple AEAD operations without repeating the key schedule. It also allows
tokens to keep track of the number of operations, and generate IVs (depending
on the cipher).
This patch:
1. implement those new functions in softoken.
With the addition of CKF_MESSAGE_* flags to various mechanism, we need
to strip them when using the version 2 API of softoken (since there are
no C_Message* function in version 2). For that we need a separate
C_GetMechanismInfo function. We use the same trick we used to have
a separate version function for the V2 interface.
Also now that the new message functions are in their own file, they
still need access to the common Session state processing functions.
those have gone from static to exported within softoken to accomidate
that. Same with sftk_MapDecryptError() (sftk_MapVerifyError() was also
made global, though nothing else is yet using it).
Only C_MessageEncrptInit(), C_EncryptMessage(), C_MessageEncryptFinal,
C_MessageDecryptInit(), C_DecryptMessage(), and C_MessageDecryptFinal
are implemented. C_EncryptMessageBegin(), C_EncryptMessageNext(),
C_DecryptMessageBegin(), and C_DecryptMessageNext() are all
part of the multi-part withing a multi-part operation and
are only necessary for things like S/MIME (potentially). If we wanted
to implement them, we would need more functions exported from freebl
(and initaead, updateaead, finalaead for each mechanism type).
2. make those interfaces call aes_gcm and chacha20_poly1503
(and make adjustments for those ciphers).
For AES, I added a new function AES_AEAD, which handles both encrypt
and decrypt. Internally, the gcm functions (both the generic gcm and
the intel gcm wrapper) had their init functions split into key scheduling
and counter mode/tag initialization. The latter is still called from
init, but the former is now for each update call. IV generation is
handled by a single function in gcm.c, and shared with intel_gcm_wrapper.c
Since the AES functions already know about the underlying PKCS #11
mechanism parameters, the new AEAD functions also parse the PKCS #11 GCM
parameters.
For Chacha/Poly new aead update functions were created called
ChaChaPoly1305_Encrypt and ChaChaChaPoly1305_Decrypt. There was no
Message specific initialization in the existing chacha_init, so no
changes were needed there. The primary difference between
_Encrypt/_Decrypt and _Seal/_Open is the fact that the tag is put at
the end of the encrypted data buffer in the latter, and in a generic
buffer in the former.
3. create new pk11wrap interfaces that also squash the api differences
between the various mechanisms for aead (similiar to the way we do it for
CBC and ECB crypto today).
To accomplish this I added PK11_AEADOp() and PK11_AEADRawOp(). Both
functions handle the case where the token only supports the single shot
interface, by using the single short interface to simulate the
Message interface. The PK11_AEADOp() also smooths out the
differences in the parameters and symantics of the various mechanism
so the application does not need to worry about the PKCS #11 differences
in the mechanism. Both use contexts from the standard
PK11_CreateContext(), so key schedules are done once for each key rather
than once for each message. MESSAGE/AEAD operations are selected by adding
the psuedo attribute flag CKA_NSS_MESSAGE to the requested operation
(CKA_ENCRYPT, CKA_DECRYPT, CKA_SIGN, CKA_VERIFY).
4. write tests for the new interfaces
Tests were added to make sure the PK11_AEADRawOp interface works,
The single shot interface is used to test output of the message interface
we also use two test only functions to force the connection to use
the simulation interface, which is also compared to the non-simulate
inteface. The AES_GCM also tests various IV generators.
Differential Revision: https://phabricator.services.mozilla.com/D67552
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update to PKCS #11 v3.0 part 2.
Create the functions and switch to the C_Interface() function to fetch the PKCS #11 function table. Also PKCS #11 v3.0 uses a new fork safe interface. NSS can already handle the case if the PKCS #11 module happens to be fork safe (when asked by the application to refresh the tokens in the child process, NSS can detect that such a refresh is not necessary and continue. Softoken could also be put in fork_safe mode with an environment variable. With this patch it's the default, and NSS asks for the fork safe API by default. Technically softoken should implement the old non-fork safe interface when PKCS #11 v2.0 is called, but NSS no longer needs it, and doing so would double the number of PKCS #11 interfaces are needed. You can still compile with fork unsafe semantics, and the PKCS #11 V3.0 module will do the right thing and not include the fork safe flag. Firefox does not fork(), so for firefox this is simply code that is no longer compilied.
We now use C_GetInterface, which allows us to specify what kind of interface we want (PKCS #11 v3.0, PKCS #11 v2.0, fork safe, etc.). Vendor specific functions can now be accessed through the C_GetInterface. If the C_GetInterface function does not exists, we fall bak to the old C_GetFunctionList.
There are 24 new functions in PKCS #11 v3.0:
C_GetInterfaceList - return a table of all the supported interfaces
C_GetInterface - return a specific interface. You can specify interface name, version and flags separately. You can leave off any of these and you will get what the token thinks is the best match of the interfaces that meet the criteria. We do this in softoken by the order of the interface list.
C_SessionCancel - Cancel one or more multipart operation
C_LoginUser - Supply a user name to C_Login(). This function has no meaning for softoken, so it just returns CKR_OPERATION_NOT_INITIALIZED under the theory that if we in the future want to support usernames, the NSS db would need special initialization to make that happen.
C_Message* and C_*Message* (20 functions in all) are the new AEAD interface (they are written generally so that it can be used for things other than AEAD). In this patch they are unimplemented (see the next patch).
This patch adds regular (NSC_) and FIPS (FC_) versions of these functions.
Also when creating the PKCS #11 v2.0 interface, we had to create a 2.0 specific version of C_GetInfo so that it can return a 2.40 in the CK_VERSION field rather than 3.00. We do this with #defines since all the function tables are generated automagically with pkcs11f.h.
Differential Revision: https://phabricator.services.mozilla.com/D67240
|
| |
|
|
|
|
| |
Remove support for RSAE in delegated credentials (both in DC signatures and SPKIs), add SignatureScheme list functionality to initial DC extension.
Differential Revision: https://phabricator.services.mozilla.com/D65252
|
| |
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D65945
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chacha20Poly1305. r=kjacobs
***
Bug 1612493 - Import AVX2 code from HACL*
***
Bug 1612493 - Add CPU detection for AVX2, BMI1, BMI2, FMA, MOVBE
***
Bug 1612493 - New flag NSS_DISABLE_AVX2 for freebl/Makefile and freebl.gyp
***
Bug 1612493 - Disable use of AVX2 on GCC 4.4 which doesn’t support -mavx2
***
Bug 1612493 - Disable tests when the platform doesn't have support for AVX2
Differential Revision: https://phabricator.services.mozilla.com/D64718
|
