I'm writing a parse tool to extract each field of P12 file in C language, OpenSSL is too huge for my project.
After reading PKCS# series documents and ASN.1 documents, I understand the basic parse step.
I use OpenSSL to generate a self-signed P12 fileļ¼there're some questions during parsing:
Why Certificate is not stored in a Safebag, in my case it's stored in EncryptedData field?
What does the localKeyId attribute mean? it has an OctetString, what is the OctectString used for?
Why the contentType of encryptedContentInfo is id-data? I think it should be id-encryptedData. In my case, Certificate is stored in encryptedContentInfo field.
Thanks,
CZ
The PKCS12 standard also available as rfc7292 formally allows a very wide range and combination of options, but in practice only a few of these options are used. There are basically 3 levels:
the file has type/structure PFX consisting mostly of a PKCS7/CMS ContentInfo which theoretically can be 'data' or 'signed-data' but in practice is always the former (with the nominally optional MacData appended) and contains
'AuthenticatedSafe' which is a sequence of one or more (almost always more) ContentInfo(s) each of which (separately) may be encrypted or not and contains (after decryption if applicable)
a sequence of one of more 'bag'(s) each of which contains actual data of a certain type such as an encrypted privatekey or a certificate along with optional attributes.
In practice there is usually:
one CI (at level 2) with PKCS7/CMS type 'encrypted-data' using a very weak algorithm (RC2-40) containing one or more CertBag(s) each containing a cert plus any attributes for it, and
one or more CI(s) (each) with type 'data' containing a PKCS8ShroudedKeyBag containing an encrypted privatekey (using PKCS8 as stated) usually using a strong algorithm commonly 3DES, plus attributes.
My answer here shows the first levels of parsing to find the encryption details; further parsing requires decryption as shown (for a specific case) in my answer here.
As mentioned all bags can have attributes; in practice depending on the implementation some bags may have the 'friendlyName' attribute with a value intended for people to use, and if a matching privatekey and cert are present they both have a 'localKeyId' attribute with the same value to tie them together, as explained in my answer to a different but related Q. 'localKeyId' is not intended for people to use and you should not normally present it to people.
Related
I am generating RSA signature using RSA_PKCS1_PSS_PADDING. I am setting digest algorithm as SHA256 using EVP_get_digestbyname() and EVP_DigestSignInit(). And salt length parameter as -1 using EVP_PKEY_CTX_set_rsa_pss_saltlen().
I have EVP_MD_CTX, EVP_MD and EVP_PKEY_CTX structures used for signature generation.
How can I get the name of Mask generation algorithm name used by OpenSSL by default? Is there any API provided for getting it?
Edit: OpenSSL version used: 1.1.0g.
RSASSA-PSS is in practice always used with MGF1 as the Mask Generation Function. The only variation is which Message Digest is used internally by MGF1.
Sometime that's the same Message Digest as the one used for hashing the message and building the tag in PSS, because that makes the most sense. Other times it is SHA-1 because that used to be the default MD for early RSASSA-PSS APIs, thus for the associated MGF1.
In an ideal world, some attribute (in the signature, or/and in the public key certificate used to check the signature) would tell MGF1-with-such-MD, perhaps by way of some Object IDentifier like we have to specify PSS. But crypto APIs are hell.
In order to control what Message Digest is used by MGF1, we want something on the tune of what -sigopt rsa_mgf1_md:sha256 does in the openssl dgst command.
My best guess is to set the MGF1 digest using
assert(EVP_PKEY_CTX_set_rsa_mgf1_md(ctx, EVP_sha256)>=0);
or get it using EVP_PKEY_CTX_get_rsa_mgf1_md() as documented:
The EVP_PKEY_CTX_get_rsa_mgf1_md() macro gets the MGF1 digest for ctx. If not explicitly set the signing digest is used. The padding mode must have been set to RSA_PKCS1_OAEP_PADDING or RSA_PKCS1_PSS_PADDING.
I don't understand why JWS unprotected headers exist.
For some context: a JWS unprotected header contains parameters that are not integrity protected and can only be used per-signature with JSON Serialization.
If they could be used as a top-level header, I could see why someone could want to include a mutable parameter (that wouldn't change the signature). However, this is not the case.
Can anyone think of a use-case or know why they are included in the spec?
Thanks!
JWS Spec
The answer by Florent leaves me unsatisfied.
Regarding the example of using a JWT to sign a hash of a document... the assertion is that the algorithm and keyID would be "sensitive data" that needs to be "protected". By which I suppose he means "signed". But there's no need to sign the algorithm and keyID.
Example
Suppose Bob creates a signed JWT, that contains an unprotected header asserting alg=HS256 and keyid=XXXX1 . This JWT is intended for transmission to Alice.
Case 1
Suppose Mallory intercepts the signed JWT sent by Bob. Mallory then creates a new unprotected header, asserting alg=None.
The receiver (Alice) is now responsible for verifying the signature on the payload. Alice must not be satisfied with "no signature"; in fact Alice must not rely on a client (sender) assertion to determine which signing algorithm is acceptable for her. Therefore Alice rejects the JWT with the contrived "no signature" header.
Case 2
Suppose Mallory contrives a header with alg=RS256 and keyId=XXX1. Now Alice tries to validate the signature and finds either:
the algorithm is not compliant
the key specified for that algorithm does not exist
Therefore Alice rejects the JWT.
Case 3
Suppose Mallory contrives a header with alg=HS256 and keyId=ZZ3. Now Alice tries to validate the signature and finds the key is unknown, and rejects the JWT.
In no case does the algorithm need to be part of the signed material. There is no scenario under which an unprotected header leads to a vulnerability or violation of integrity.
Getting Back to the Original Question
The original question was: What is the purpose of an unprotected JWT header?
Succinctly, the purpose of an unprotected JWS header is to allow transport of some metadata that can be used as hints to the receiver. Like alg (Algorithm) and kid (Key ID). Florent suggests that stuffing data into an unprotected header could lead to efficiency. This isn't a good reason. Here is the key point: The claims in the unprotected header are hints, not to be relied upon or trusted.
A more interesting question is: What is the purpose of a protected JWS header? Why have a provision that signs both the "header" and the "payload"? In the case of a JWS Protected Header, the header and payload are concatenated and the result is signed. Assuming the header is JSON and the payload is JSON, at this point there is no semantic distinction between the header and payload. So why have the provision to sign the header at all?
One could just rely on JWS with unprotected headers. If there is a need for integrity-protected claims, put them in the payload. If there is a need for hints, put them in the unprotected header. Sign the payload and not the header. Simple.
This works, and is valid. But it presumes that the payload is JSON. This is true with JWT, but not true with all JWS. RFC 7515, which defines JWS, does not require the signed payload to be JSON. Imagine the payload is a digital image of a medical scan. It's not JSON. One cannot simply "attach claims" to that. Therefore JWS allows a protected header, such that the (non JSON) payload AND arbitrary claims can be signed and integrity checked.
In the case where the payload is non-JSON and the header is protected, there is no facility to include "extra non signed headers" into the JWS. If there is a need for sending some data that needs to be integrity checked and some that are simply "hints", there really is only one container: the protected header. And the hints get signed along with the real claims.
One could avoid the need for this protected-header trick, by just wrapping a JSON hash around the data-to-be-signed. For example:
{
"image" : "qw93u9839839...base64-encoded image data..."
}
And after doing so, one could add claims to this JSON wrapper.
{
"image" : "qw93u9839839...base64-encoded image data..."
"author" : "Whatever"
}
And those claims would then be signed and integrity-proected.
But in the case of binary data, encoding it to a string to allow encapsulation into a JSON may inflate the data significantly. A JWS with a non-JSON payload avoids this.
HTH
The RFC gives us examples of unprotected headers as follows:
A.6.2. JWS Per-Signature Unprotected Headers
Key ID values are supplied for both keys using per-signature Header Parameters. The two JWS Unprotected Header values used to represent these key IDs are:
{"kid":"2010-12-29"}
and
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
https://datatracker.ietf.org/doc/html/rfc7515#appendix-A.6.2
The use of kid in the example is likely not coincidence. Because JWS allows multiple signatures per payload, a cleartext hint system could be useful. For example, if a key is not available to the verifier (server), then you can skip decoding the protected header. The term "hint" is actually used in the kid definition:
4.1.4. "kid" (Key ID) Header Parameter
The "kid" (key ID) Header Parameter is a hint indicating which key was used to secure the JWS. This parameter allows originators to explicitly signal a change of key to recipients. The structure of the "kid" value is unspecified. Its value MUST be a case-sensitive string. Use of this Header Parameter is OPTIONAL.
https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.4
If we look at Key Identification it mentions where you a kid does not have to be integrity protected (ie: part of unprotected headers): (emphasis mine)
6. Key Identification
It is necessary for the recipient of a JWS to be able to determine the key that was employed for the digital signature or MAC operation. The key employed can be identified using the Header Parameter methods described in Section 4.1 or can be identified using methods that are outside the scope of this specification. Specifically, the Header Parameters "jku", "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256" can be used to identify the key used. These Header Parameters MUST be integrity protected if the information that they convey is to be utilized in a trust decision; however, if the only information used in the trust decision is a key, these parameters need not be integrity protected, since changing them in a way that causes a different key to be used will cause the validation to fail.
The producer SHOULD include sufficient information in the Header Parameters to identify the key used, unless the application uses another means or convention to determine the key used. Validation of the signature or MAC fails when the algorithm used requires a key (which is true of all algorithms except for "none") and the key used cannot be determined.
The means of exchanging any shared symmetric keys used is outside the scope of this specification.
https://datatracker.ietf.org/doc/html/rfc7515#section-6
Simplified, if you have a message that by somebody modifying the kid will refer to another key, then the signature itself will not match. Therefore you don't have to include the kid in the protected header. A good example of the first part, where the information they convey is to be utilized in a trust decision, is the ACME (aka the Let's Encrypt protocol). When creating an account, and storing the key data, you want to trust the kid. We want to store kid, so we need to make sure it's valid. After the server has stored the kid and can use it to get a key, we can push messages and reference the kid in unprotected header (not done by ACME but possible). Since we're only going to verify the signature, then the kid is used a hint or reference to which kid was used for the account. If that field is tampered with, then it'll point to a nonexistent of completely different key and fail the signature the check. That means the kid itself is "the only information used in the trust decision".
There's also more theoretical scenarios that, knowing how it works you can come up with.
For example: the idea of having multiple signatures that you can pass on (exchange). A signing authority can include one signature that can be for an intermediary (server) and another for the another recipient (end-user client). This is differentiated by the kid and the server doesn't need to verify or even decode the protected header or signature. Or perhaps, the intermediary doesn't have the client's secret in order to verify a signature.
For example, a multi-recipient message (eg: chat room) could be processed by a relay/proxy and using kid in the unprotected header, pass along a reconstructed compact JWS (${protected}.${payload}.${signature}) for each recipient based on kid (or any other custom unprotected header field, like userId or endpoint).
Another example, would be a server with access to many different keys and a cleartext kid would be faster than iterating and decoded each protected field to find which one.
From one perspective, all you're doing is skipping base64url decoding the protected header for performance, but if you're going to proxy/relay the data, then you're not polluting the protected header which is meant for another recipient.
Is there any way to verify the OpenSSL signature using only {signature,hashed message} pair, skipping the original file to be presented for verification?
I need to verify the signature with only {signature,hashed message} pair remotely so using the original file is cumbersome specially when its very large.
Is there any way to verify the OpenSSL signature using only hash value and without needing the original file?
Yes, but there are strings attached.
The scheme which requires the original message to be presented to the verifying function is a Signature Scheme with Appendix (SSA). A scheme like the old PKCS #1.0 signing is an example of it.
The scheme which does not require the original message is a Signature Scheme with Recovery (PSSR). In a PSSR, the encoded message is part of the signature and masked. A scheme like the new PKCS #2.0 PSSR signing is an example of it.
There are no schemes that take just a hash, as far as I know. You have to have the {message,signature} pair. Allowing the message to be disgorged from the signing or verification can be a security violation.
OpenSSL provides both of them, as does most other security libraries, like Botan, Crypto++, NSS, etc.
Also see RSA signature on TLS on Information Security Stack Exchange.
I have been trying to verify the signature with hash value remotely so using the original file is cumbersome specially when its very large.
That's the insecure thing signature schemes want to avoid....
I realize that there are a lot of similar questions to the one I am about to ask already on Stack Overflow, but none of them have clear answers that really satisfy my needs, so here we go:
My program receives an ASN.1 encoded RSA public key over the network. I have the data stored in a simple NSData instance. I wish to use that public key to encode 16 bytes of data and return those over the network. From my research the best way to do this seems to be to use a SecKeyRef. According to the ridiculously vague documentation provided by Apple this can be done using some code. However, their code presents a problem. Every time I want to use a public key I need to add it to the keychain and give it a unique identifier. The problem with this is that this key is to be used only once. I am looking for a way to obtain a SecKeyRef for a key that is not in the keychain and is created from an ASN.1 encoded key.
I have also considered the possibility of converting it to common PEM by base64-encoding and wrapping it in '-----BEGIN PUBLIC KEY-----' and '-----END PUBLIC KEY-----' and then loading it into a SecKeyRef, but I haven't seen a way to do this either.
Also, I don't have much of a choice in the type of key, key format, etc. Its from a 3rd party java server. Yay.
I currently have this alternate method of loading keys that (maybe) doesn't add them to the key chain but the key evidently (by trial and error :D) is not in DER format and therefore I can't load it like this.
SecCertificateRef certificateRef = SecCertificateCreateWithData(kCFAllocatorDefault, (__bridge CFDataRef)data); //data contains the public key - received over the network
SecPolicyRef policyRef = SecPolicyCreateBasicX509();
SecTrustRef trustRef;
OSStatus status = SecTrustCreateWithCertificates(certificateRef, policyRef, &trustRef);
NSAssert(status == errSecSuccess, #"SecTrustCreateWithCertificates failed.");
SecTrustResultType trustResult;
status = SecTrustEvaluate(trustRef, &trustResult);
NSAssert(status == errSecSuccess, #"SecTrustEvaluate failed.");
SecKeyRef publicKey = SecTrustCopyPublicKey(trustRef); //The Result :)
NSAssert(publicKey != NULL, #"SecTrustCopyPublicKey failed.");
if (certificateRef) CFRelease(certificateRef);
if (policyRef) CFRelease(policyRef);
if (trustRef) CFRelease(trustRef);
PS: Why does apple make this so hard? Statically linking OpenSSL would be easy, but then all sorts of export regulations and other problems apply.
The problem was apparently with the source of the "certificate", which really wasn't much more than the key wrapped in some DER tags.
On the plus side thanks to the black magic in this http://blog.wingsofhermes.org/?p=75 blog post, I have successfully managed to achieve most of my goals.
Success:
Key loaded from data, not a file
Encryption of secret (AES) key successfully read by java server.
Less success:
Had to use a unique identifier, but I reuse it, so no need for a crazy naming scheme.
Key temporarily added to keychain, but I remove it after its one time use, so that works out too.
I am still not too clear on what the array of if statements mixed with loops and tons of magic numbers does exactly, but at least it works and since the key will always come from the same source, it shouldn't break unless they change the java security provider...oh wait thats actually kinda likely...oh well...at least its a little bit specific in the Java 7 standards.
*crosses fingers* *hopes nothing breaks*
In our application we generate certificates for internal entities like platform and user. Our internal entities are identified by custom DNs:
Platform DN: p=platformName
User DN: cn=userName,p=platformName
We tried to generate X.509 certificate for platform or user with popular tools like openssl, keytool, implementation of javax.security (BouncyCastle), e.g.:
keytool -genkey -dname "p=platformName" -alias platformName
However, those tools do not accept/recognize keyword "P" or require certain keywords like "CN" in certificate subject DN.
How to issue certificate to an entity with custom DN format?
Note: We do not need to have DNs containing standard keywords (CN, OU, etc.), because all certificates will be for internal use of our products (will not be validated by 3rd party or included in certificate chain).
We do not need to have DNs containing standard keywords (CN, OU, etc.)
How to issue certificate to an entity with custom DN format?
The attributes or fields displayed are a presentation level detail. There is no distinguished DN field per se. The fields used to form the DN are a mashup of other attributes and are arbitrarily chosen. The common ones are C, O, OU, CN, etc.
Attributes or fields like C, O, OU, CN have well known OIDs associated with them. There are other OIDs you can use that are recognized by tools. For example, the ITU's X.520 list hundreds of them. There are other standards that declare them too. For example, the email address attribute is from PKCS 9 and has an OID of 1.2.840.113549.1.9.1.
As Burhan Khalid stated, you can even add your own name/value pairs by making up OIDs (some hand waiving). However, other presentation tools won't know how to display them. That is, they won't know the "friendly name".
Because other tools don't recognize your OID for platform (or "p=..."), that's why you are getting ... those tools do not accept/recognize keyword "P". The tools don't know how to deal with your custom attributes.
I can only speak for openssl, as I am not familiar with other tools.
From the openssl docs
ASN1 OBJECT CONFIGURATION MODULE
This module has the name oid_section. The value of this variable
points to a section containing name value pairs of OIDs: the name is
the OID short and long name, the value is the numerical form of the
OID. Although some of the openssl utility sub commands already have
their own ASN1 OBJECT section functionality not all do. By using the
ASN1 OBJECT configuration module all the openssl utility sub commands
can see the new objects as well as any compliant applications.
So what you have to do is create these oids in /etc/openssl.conf or wherever the file is for your platform, then openssl will not give you the Subject attribute p has no known NID, skipped message, which I suspect is what you are getting now.