|
|
|
#1951: [patch] verification of X.509 certificates that contain an RSASSA-PSS signature
|
|
|
|
X
Ticket metadata
|
|
|
X
The Basics
|
|
| Id: |
1951 |
| Status: |
resolved |
| Left: |
0 min |
| Priority: |
0/0 |
| Queue: |
OpenSSL-Bugs |
|
|
X
People
|
|
| Owner: |
steve
<steve@openssl.org>
|
| Requestors: |
lists@kaiser.cx
|
| Cc: |
|
| AdminCc: |
|
|
|
|
X
Links
|
|
| Depends on: |
|
| Depended on by: |
|
| Parents: |
|
| Children: |
|
| Refers to: |
|
| Referred to by: |
|
|
|
X
Attachments
|
|
pssVerify.SNAP-10-02-07.updated.patch
pssVerify.patch
pssX509Verify.09-06-07.patch
|
|
X
More about Martin Kaiser
|
|
Comments about this user:
No comment entered about this user
This user's 10 highest priority tickets:
Groups this user belongs to:
|
|
|
|
X
History
|
Display mode:[Brief headers] [Full headers]
|
| # |
|
Mon Jun 08 10:46:29 2009 |
lists@kaiser.cx - Ticket created
|
|
|
The attached patch against openssl-SNAP-20090607 adds support for X.509
certificates that contain an RSASSA-PSS signature (see PKCS1 #2.1 and
RFC 4055).
At the moment, only verification is supported, PSS parameters must be
the default ones (either omitted or coded explicitly).
The main idea of the patch is to use a new EVP_MD for "sha1 coupled to
PSS", see my mail from 1st of June (20090601112625.GA3752@kaiser.cx).
Thanks for your feedback and/or for merging this patch.
|
| # |
|
Tue Jun 09 13:46:17 2009 |
steve - Correspondence added
|
|
|
|
> [lists@kaiser.cx - Mon Jun 08 10:46:29 2009]:
>
>
> The attached patch against openssl-SNAP-20090607 adds support for X.509
> certificates that contain an RSASSA-PSS signature (see PKCS1 #2.1 and
> RFC 4055).
>
> At the moment, only verification is supported, PSS parameters must be
> the default ones (either omitted or coded explicitly).
>
> The main idea of the patch is to use a new EVP_MD for "sha1 coupled to
> PSS", see my mail from 1st of June (20090601112625.GA3752@kaiser.cx).
>
The new pkey API was designed to avoid tieing digests to signature
algorithms (e.g. sha1 can now be used to handle RSA and DSA signatures).
Having looked through the API and standards it seems this can't be
avoided without some extensions to the EVP_PKEY API.
I'll look into how that could be done when I'm not snowed under with
other tasks.
Do you have some examples of certificates signed with PSS? They would be
useful for testing purposes.
|
| # |
|
Tue Jun 09 13:46:18 2009 |
RT_System - Status changed from 'new' to 'open'
|
|
|
|
|
| # |
|
Tue Jun 09 13:51:57 2009 |
steve - Taken
|
|
|
|
|
| # |
|
Mon Jun 22 22:13:42 2009 |
lists@kaiser.cx - Correspondence added
|
|
|
|
Steve, all,
> The new pkey API was designed to avoid tieing digests to signature
> algorithms (e.g. sha1 can now be used to handle RSA and DSA signatures).
i.e. you're going to remove the pkey_type field in the EVP_MD structure?
> Having looked through the API and standards it seems this can't be
> avoided without some extensions to the EVP_PKEY API.
Some unsorted thoughts:
RSA_PKEY_CTX already contains the required fields to store some of the PSS
parameters. The mask generation function and its parameters are missing.
The low-level routines have MGF1 hard-coded, the digest for MGF1 must be
the same as for the entire PSS. This is not a big limitation.
An RSA key in an X.509 certificate looks exactly the same, no matter if
the signature is PKCSv1.5 or PSS.
The decision table in obj_xref.txt seems to be the problem. This doesn't
work for PSS, you can't determine the digest without parsing the PSS
parameters.
We'll need a way to set these parameters in the EVP_PKEY_CTX or
RSA_PKEY_CTX respectively. I've (ab)used the md_ctrl function for this.
Could we just add a similar function pointer directly to the
EVP_PKEY_CTX structure?
> Do you have some examples of certificates signed with PSS? They would be
> useful for testing purposes.
I've uploaded sample certificates to
http://www.kaiser.cx/x509Pss.html
Best regards,
Martin
|
| # |
|
Tue Jun 23 19:11:45 2009 |
steve - Correspondence added
|
|
|
|
> [lists@kaiser.cx - Mon Jun 22 22:13:42 2009]:
>
> Steve, all,
>
> > The new pkey API was designed to avoid tieing digests to signature
> > algorithms (e.g. sha1 can now be used to handle RSA and DSA signatures).
>
> i.e. you're going to remove the pkey_type field in the EVP_MD structure?
>
Well that can stay for compatibility reasons. The actual "link" was that
before 1.0.0 you could only sign using EVP_sha1() with RSA keys, DSA
keys needed a bogus EVP_dss1() "clone" digest. Similarly for other
digests and public key algorithms needed this stuff. There were horrible
hacks all over the place to switch to the correct bogus digest type.
That's gone now.
> > Having looked through the API and standards it seems this can't be
> > avoided without some extensions to the EVP_PKEY API.
>
> Some unsorted thoughts:
>
> RSA_PKEY_CTX already contains the required fields to store some of the PSS
> parameters. The mask generation function and its parameters are missing.
> The low-level routines have MGF1 hard-coded, the digest for MGF1 must be
> the same as for the entire PSS. This is not a big limitation.
>
> An RSA key in an X.509 certificate looks exactly the same, no matter if
> the signature is PKCSv1.5 or PSS.
>
Well there is also a PSS key type which is RSA+restrictions defined in
PKCS#1 2.0. That's an RSA key that can *only* be used with PSS.
> The decision table in obj_xref.txt seems to be the problem. This doesn't
> work for PSS, you can't determine the digest without parsing the PSS
> parameters.
>
Yes, probably will need a special value for the digest type NID_undef
for example which means "the public key algorithm method will work out
the digest type".
> We'll need a way to set these parameters in the EVP_PKEY_CTX or
> RSA_PKEY_CTX respectively. I've (ab)used the md_ctrl function for this.
> Could we just add a similar function pointer directly to the
> EVP_PKEY_CTX structure?
>
That's what I'm considering. We pass (say) a NULL for the digest type in
EVP_DigestVerifyInit() and call a ctrl in the associated public key
method to let it decide which digest and parameters to use. The
functionality isn't in EVP_DigestVerifyInit() yet it just uses a
"default" digest if NULL is passed in.
> > Do you have some examples of certificates signed with PSS? They would be
> > useful for testing purposes.
>
> I've uploaded sample certificates to
>
> http://www.kaiser.cx/x509Pss.html
>
Thanks.
|
| # |
|
Tue Aug 25 22:57:35 2009 |
lists@kaiser.cx - Correspondence added
|
|
|
|
Steve, all,
I recently found some more time to look into this. In order to make sure
that the next attempt is in line with the rest of the code, I need some
more discussion.
> > The decision table in obj_xref.txt seems to be the problem. This
> > doesn't work for PSS, you can't determine the digest without parsing
> > the PSS parameters.
> Yes, probably will need a special value for the digest type NID_undef
> for example which means "the public key algorithm method will work out
> the digest type".
> > We'll need a way to set these parameters in the EVP_PKEY_CTX or
> > RSA_PKEY_CTX respectively. I've (ab)used the md_ctrl function for this.
> > Could we just add a similar function pointer directly to the
> > EVP_PKEY_CTX structure?
> That's what I'm considering. We pass (say) a NULL for the digest type in
> EVP_DigestVerifyInit() and call a ctrl in the associated public key
> method to let it decide which digest and parameters to use. The
> functionality isn't in EVP_DigestVerifyInit() yet it just uses a
> "default" digest if NULL is passed in.
The ctrl would require a X509_ALGOR * an input so that all PSS
parameters can be determined. This struct is available only in
ASN1_item_verify(). The ctrl however could be part of EVP_PKEY_METHOD
and will be called from EVP_DigestVerifyInit(). Any idea how to pass on
the struct?
Alternatively, I thought of adding the "work out the paramters" function
to EVP_PKEY_ASN1_METHOD's ctrl. It fits there as it involves some ASN1
parsing. But the resulting PSS parameters have to be stored in
RSA_PKEY_CTX. According to your last mails, this is the best place to
put the params. But it's not accessible from EVP_PKEY_ASN1_METHOD.
A third approach would be to run EVP_DigestVerifyInit() with a NULL
EVP_MD parameter (just modify it to not use a default md). When the
functions returns, we use the resulting EVP_PKEY_CTX in ASN1_item_verify
and call its pctx->pmeth->ctrl directly from ASN1_item_verify(),
supplying the X509_ALGOR * parameter.
Any thoughts what would be the best appoach?
Best regards,
Martin
|
| # |
|
Mon Sep 21 22:43:21 2009 |
martin@kaiser.cx - Correspondence added
|
|
|
|
Steve, all,
here's another idea in draft stage. Please give me feedback before I
start working out the details.
In obj_xref.txt, we define
rsassaPss undef rsaEncryption
We add two components for pss to rsa_st
struct rsa_st
{
[...]
const EVP_MD *pssDigest; /* pointer ok or should we store the NID? */
int pssSaltlen;
};
and define a function to decode the parameters of the algorithm used in
the X.509 certificate
static int rsa_param_decode(EVP_PKEY *pkey, const unsigned char **pder, int derlen)
{
/* TODO: parse and check paramters */
if (pkey && pkey->type == EVP_PKEY_RSA)
{
pkey->pkey.rsa->pssDigest = EVP_sha1();
pkey->pkey.rsa->pssSaltlen = 20;
}
return 1;
}
In ASN1_item_verify(), we use the EVP_DigestVerify...() API and call
the pkey's param_decode() method
...
if (pkey->ameth->param_decode)
{
/* TODO: pass real algorithm parameters */
pkey->ameth->param_decode(pkey, NULL, 0);
}
else printf("no param_decode method defined\n");
if (!EVP_DigestVerifyInit(&mctx,&pctx,md, NULL, pkey))
...
md may be NULL if message digest is undef is obj_xref.txt
(some low-level routines must be changed to get this result)
In do_sigver_init(), we check for type==NULL and set the pss parameters
in this case
...
}
else if (EVP_PKEY_sign_init(ctx->pctx) <= 0)
return 0;
}
if (type == NULL)
{
if (pkey && pkey->type == EVP_PKEY_RSA && pkey->pkey.rsa->pssDigest)
{
type = pkey->pkey.rsa->pssDigest;
EVP_PKEY_CTX_set_rsa_padding(ctx->pctx, RSA_PKCS1_PSS_PADDING);
EVP_PKEY_CTX_set_rsa_pss_saltlen(ctx->pctx, pkey->pkey.rsa->pssSaltlen);
}
else
{
int def_nid;
if (EVP_PKEY_get_default_digest_nid(pkey, &def_nid) > 0)
type = EVP_get_digestbynid(def_nid);
}
}
if (type == NULL)
{
EVPerr(EVP_F_DO_SIGVER_INIT, EVP_R_NO_DEFAULT_DIGEST);
...
Does this approch look ok?
Best regards,
Martin
|
| # |
|
Sun Feb 07 20:31:00 2010 |
lists@kaiser.cx - Correspondence added
|
|
|
Dear OpenSSL team and all,
finally, here's my patch (against today's 1.1 snapshot) for verification
of X.509 certificates using an RSASSA-PSS signature. I believe it is
fairly complete in terms of checking parameters.
The patch follows the idea that I outlined in previous posts
- two new ASN.1 objects for pss, mgf1
- in obj_xref.txt, pss uses digest undef
-> verify routine has to determine the digest by itself
- ASN1_item_verify() uses EVP_DigestVerify... API
- rsa_st gets two new elements
- param_decode method for rsa parses rsa key's parameters in the
certificate
- at verification time, pss parameters are copied into EVP_PKEY_CTX
This time, I really do hope to get some feedback. Reviewing this won't
be wasted time, I'm happy to improve the code until it is ready for
merging.
As such pss certificates are now being deployed by the millions for
digital pay-tv in Europe (www.ci-plus.com), I feel that OpenSSL should
support them.
Best regards,
Martin
|
| # |
|
Wed Feb 10 14:32:54 2010 |
steve - Correspondence added
|
|
|
|
> [lists@kaiser.cx - Sun Feb 07 20:31:00 2010]:
>
>
> Dear OpenSSL team and all,
>
> finally, here's my patch (against today's 1.1 snapshot) for verification
> of X.509 certificates using an RSASSA-PSS signature. I believe it is
> fairly complete in terms of checking parameters.
>
> The patch follows the idea that I outlined in previous posts
>
> - two new ASN.1 objects for pss, mgf1
> - in obj_xref.txt, pss uses digest undef
> -> verify routine has to determine the digest by itself
> - ASN1_item_verify() uses EVP_DigestVerify... API
> - rsa_st gets two new elements
> - param_decode method for rsa parses rsa key's parameters in the
> certificate
> - at verification time, pss parameters are copied into EVP_PKEY_CTX
>
> This time, I really do hope to get some feedback. Reviewing this won't
> be wasted time, I'm happy to improve the code until it is ready for
> merging.
>
> As such pss certificates are now being deployed by the millions for
> digital pay-tv in Europe (www.ci-plus.com), I feel that OpenSSL should
> support them.
>
As has been indicated the PSS ASN1 module is incorrect. Does that
actually verify PSS signatures correctly with non-default algorithms?
I'd expect ASN1 parsing errors.
A quick look through (I'm not short of things to do at the moment
alas...) suggests ctrl return codes aren't checked properly in a number
of places.
I also find the lack of any use of the PSS OID as rather strange. The
specifications I've seen should require it is at least checked.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
|
| # |
|
Mon Feb 15 23:16:48 2010 |
lists@kaiser.cx - Correspondence added
|
|
|
Hello Steve,
thanks for your feedback.
Thus wrote Stephen Henson via RT (rt@openssl.org):
> As has been indicated the PSS ASN1 module is incorrect. Does that
> actually verify PSS signatures correctly with non-default algorithms?
> I'd expect ASN1 parsing errors.
I got Francesco's point and corrected this. The certificates I used for
testing either had the parameters omitted or were generated by myself
using the same wrong definition, that's why I didn't spot the problem.
I'll update the sample certificates on my website shortly
(http://www.kaiser.cx/x509Pss.html)
> A quick look through (I'm not short of things to do at the moment
> alas...) suggests ctrl return codes aren't checked properly in a number
> of places.
Are you refering to this?
if (type == NULL)
{
if (EVP_PKEY_CTX_ctrl(ctx->pctx, -1, ctx->pctx->operation,
EVP_PKEY_CTRL_PARAM_SET_FROM_PKEY, 0, pkey))
{
EVP_PKEY_CTX_ctrl(ctx->pctx, -1, ctx->pctx->operation,
EVP_PKEY_CTRL_GET_DIGEST, 0, &type);
}
....
I'll add a clean error checking.
> I also find the lack of any use of the PSS OID as rather strange. The
> specifications I've seen should require it is at least checked.
I've added a function
void EVP_MD_CTX_set_padmode_from_nid(EVP_MD_CTX *ctx, int nid)
that sets EVP_MD_CTX_FLAG_PAD_PSS when it sees the PSS nid. This ctx is
then passed into EVP_DigestVerifyInit.
pkey_rsa_verifyctx_init() converts the flag into RSA_PKEY_CTX' pad_mode
parameter. The pad_mode is checked when the ctrls set the pss
parameters.
Please see the attached patch (against 2010-02-07 snapshot) for a first
concept. Does this make sense to you or does it contradict your intended
use of the (yet unused) EVP_MD_CTX_FLAG_PAD_... flags?
Best regards,
Martin
|
| # |
|
Mon Feb 15 23:37:04 2010 |
steve - Correspondence added
|
|
|
|
> [lists@kaiser.cx - Mon Feb 15 23:16:48 2010]:
>
> Please see the attached patch (against 2010-02-07 snapshot) for a first
> concept. Does this make sense to you or does it contradict your intended
> use of the (yet unused) EVP_MD_CTX_FLAG_PAD_... flags?
>
Actually that flag isn't unused. It is present in OpenSSL 0.9.8 as a
hack to allow the use of different padding modes using EVP. That was
added for the FIPS 140-2 1.2 module validation. Major infrastructural
changes weren't possible under the constraints of the validation (had to
be binary compatible with 0.9.8) so the smallest compatible change was done.
I wouldn't want to do things that way for 1.0.0 and later because it
isn't flexible enough: it squeezes parameters into one flag. I'll review
your code when I have time. I'd probably go for something similar to the
way the CMS/PKCS7 code works which is to use ctrls inside the
EVP_PKEY_METHOD API..
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
|
| # |
|
Sun Mar 07 20:23:08 2010 |
steve - Correspondence added
|
|
|
|
I wouldn't advise spending any more time on this. I've been looking into
it more and it the most natural soltuion is an extension to the
EVP_PKEY_ASN1_METHOD structure which I'm currently working on (that
should support some other features too).
Unless I get some major distractions I should be able to get PSS verify
functionality in place sometime this week.
I also want to add PSS signature generation functionality but that will
take a bit longer.
CMS support for PSS would be nice too but I don't have any examples of
PSS signed messages.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
|
| # |
|
Mon Mar 08 19:16:20 2010 |
steve - Correspondence added
|
|
|
|
I've now committed code to the development branch which includes PSS
signature verification support. I'll look into PSS signing at some point
too.
Let me know of any problems.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
|
| # |
|
Tue Mar 09 23:04:58 2010 |
lists@kaiser.cx - Correspondence added
|
|
|
|
Hello Steve,
Thus wrote Stephen Henson via RT (rt@openssl.org):
> I've now committed code to the development branch which includes PSS
> signature verification support.
thanks for committing this, it looks like a clean and generic approach.
(of course, it's a pity that most of my code didn't make it into the
final version but that's life...)
> I'll look into PSS signing at some point too.
Any chance I can contribute to this, based on your approach for
verification?
A while ago, I extended my patch to support basic PSS signing. For this,
I added a -pss command line parameter to x509 which uses the default PSS
parameters and does not explicitly encode them. Instead, an empty
sequence is used to indicate default parameters.
> Let me know of any problems.
It runs ok against the sample certificates that I have here.
Do you think it makes sense to check the trailerField in
rsa_item_verify() to make sure that it is the default value?
Index: crypto/rsa/rsa_ameth.c
===================================================================
RCS file: /v/openssl/cvs/openssl/crypto/rsa/rsa_ameth.c,v
retrieving revision 1.24
diff -u -r1.24 rsa_ameth.c
--- crypto/rsa/rsa_ameth.c 8 Mar 2010 18:10:35 -0000 1.24
+++ crypto/rsa/rsa_ameth.c 9 Mar 2010 21:55:22 -0000
@@ -530,6 +530,13 @@
else
saltlen = 20;
+ /* low-level routines support only trailer field 0xbc (value 1) */
+ if (pss->trailerField && ASN1_INTEGER_get(pss->trailerField) != 1)
+ {
+ RSAerr(RSA_F_RSA_ITEM_VERIFY, RSA_R_INVALID_TRAILER);
+ goto err;
+ }
+
/* We have all parameters now set up context */
if (!EVP_DigestVerifyInit(ctx, &pkctx, md, NULL, pkey))
BTW, ticket #2131 is now obsolete ;-)
Best regards,
Martin
|
| # |
|
Thu May 27 14:57:08 2010 |
steve - Status changed from 'open' to 'resolved'
|
|
|
|
|
|
|
|
Time to display: 1.795664
|
|
