Using set_serial to control serial number size directly

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Using set_serial to control serial number size directly

Robert Moskowitz
I have worked out that:

openssl req -config openssl-root.cnf -set_serial 0x$(openssl rand -hex
19) -key private/ca.key.pem\
       -subj "$DN"\
       -new -x509 -days 7300 -sha256 -extensions v3_ca -out
certs/ca.cert.pem


allows you to override the serial number select process and thus control
what size serial number you use.

This also works for openssl ca for signing a csr, so you don't have to
deal with the serial file.

You can further parameterize this with:

-set_serial 0x$(openssl rand -hex $sn)

when sn=some number 8 to 19.

But in doing this, I can't figure out if there is a risk on serial
number size for a root CA cert as there is for any other cert.  The
nature of the attack, just to me, does not seem to apply to a root CA
cert.  So that a serial number size of 8 octets is just fine for the
root cert.

Please correct me if I don't have the risk properly understood.

thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Using set_serial to control serial number size directly

OpenSSL - User mailing list

    But in doing this, I can't figure out if there is a risk on serial
    number size for a root CA cert as there is for any other cert.

I don’t understand what attack you are concerned about, but the size of the serial number should not matter for *any* certificate.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Using set_serial to control serial number size directly

Robert Moskowitz


On 08/21/2017 09:20 AM, Salz, Rich via openssl-users wrote:
>      But in doing this, I can't figure out if there is a risk on serial
>      number size for a root CA cert as there is for any other cert.
>
> I don’t understand what attack you are concerned about, but the size of the serial number should not matter for *any* certificate.
>
This whole subject is tied into the substitution attack found with using
an MD5 hash where you could change some things in the cert and still
have a valid cert.  The solution, besides dropping MD5, was to include a
crypto random number in the beginning of the cert, and the serial was
chosen for this sacrifice.  Thus how large does this random number have
to be to defend against this attack?  is 8 octets enough or is 20 needed?

This is to make another valid cert with a different keypair.  OK, I get
this for a cert signed by an issuer.  But the root issuer?  I don't see
the attack.  Thus no need to push the root cert's serial to 20 octets.

I know I am a little cavalier in describing the attack, but that was the
basic point of why to move away from sequential serials to random and
what size (though there are other things about CAs that can be
discovered by analyzing the sequential serial numbers they used).

Meanwhile, I was wrong that -set_serial works with 'openssl ca'. The man
page was talking about in conjunction with the -CA option. With 'openssl
ca' use of the serial file is mandatory according to the man page.  
There are no command line options for it.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Using set_serial to control serial number size directly

OpenSSL - User mailing list
➢ Thus how large does this random number have

It’s also to protect against predicting serial numbers and being able to leverage that.  It’s not just (nor really mainly) the MD5 digest attacks.  According to CABForum, you need 8 octets.  No reason not to use more if you can.


➢ page was talking about in conjunction with the -CA option. With 'openssl
    ca' use of the serial file is mandatory according to the man page.  
    There are no command line options for it.

Fixed in master and will be part of the next releases; the –rand_serial flag.    

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Using set_serial to control serial number size directly

Robert Moskowitz


On 08/21/2017 09:36 AM, Salz, Rich wrote:
> ➢ Thus how large does this random number have
>
> It’s also to protect against predicting serial numbers and being able to leverage that.  It’s not just (nor really mainly) the MD5 digest attacks.  According to CABForum, you need 8 octets.  No reason not to use more if you can.

Sure there is.  On constrained systems with constrained communication
links.  Every byte counts.  My real thrust on this is for IoT.  To get
IoT developers to build around certs and know their products work with
them instead of, well we will get to it eventually.

When I work with 802.15.4 communications with a 128 byte MTU, there is
considerable debate over every byte sent.  When you tell an IoT chip
maker that they have to go from 32KB memory to 100MB, they walk out of
the room.

Oh, I want DOTS and I2NSF developers to be working with certs from the
get go, instead waiting for deployments and getting 'production' certs
and THEN discovering what works and what does not.  But IoT is in many
ways more of a challenge.

So yes, size matters.

>
>
> ➢ page was talking about in conjunction with the -CA option. With 'openssl
>      ca' use of the serial file is mandatory according to the man page.
>      There are no command line options for it.
>
> Fixed in master and will be part of the next releases; the –rand_serial flag.
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Using set_serial to control serial number size directly

OpenSSL - User mailing list
If the root is going to be trusted, make its serial number be one. ☺
Otherwise use eight bytes of random as the serial number, if you follow CABF guidelines.
 

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Using set_serial to control serial number size directly

Robert Moskowitz


On 08/21/2017 10:03 AM, Salz, Rich wrote:
> If the root is going to be trusted, make its serial number be one. ☺
> Otherwise use eight bytes of random as the serial number, if you follow CABF guidelines.

Kind of where my thinking is going.  But once I make it '1', it might as
well be 1 byte rand!  :)

Well 1 - 127 random...

But no need to make it 20 octets.  Just leave it at 8.  And yes, I can
see some jump on the 'save' 7 bytes bandwagon.  Also why I have to work
out BER to compare that sizing to DER.  Trying to do that today.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Using set_serial to control serial number size directly

OpenSSL - User mailing list
In reply to this post by Robert Moskowitz
My proposal.

Keep k bits (k/8 octets) long serial numbers for all your certificates, chose a block cipher operating on blocks of k bits, and operate this block cipher in CTR mode, with a proper secret key and secret starting counter. That way, no collision detection is necessary, you’ll be able to generate 2^(k/2) unique k bits longs serial numbers (in fact, you can generate 2^k unique serial numbers, but after 2^(k/2) you lose some security guarantees).

With 3DES, k=64, and with AES, k=128.
Since you need to make a tradeoff between security and size, you can play with lightweight block ciphers such as Simon, Speck, or find some tweakable lightweight block cipher, maybe from the ECRYPT portfolio (it’s down at this moment).

Again, the 64bits coming from a CSPRNG is for public CAs only, and the uniqueness of a serial number is a dirty hack to be able to use a non collision-resistant hash function a little longer. If you’re confident the hash function used for signature is collision resistant (for example a member of the SHA2 or SHA3 family), and you have a purely private CA, don’t bother will all this, the only hard requirement is the unicity of the tuple {CA name, serial number}.

Cordialement,
Erwann Abalea

> Le 21 août 2017 à 15:44, Robert Moskowitz <[hidden email]> a écrit :
>
>
>
> On 08/21/2017 09:36 AM, Salz, Rich wrote:
>> ➢ Thus how large does this random number have
>>
>> It’s also to protect against predicting serial numbers and being able to leverage that.  It’s not just (nor really mainly) the MD5 digest attacks.  According to CABForum, you need 8 octets.  No reason not to use more if you can.
>
> Sure there is.  On constrained systems with constrained communication links.  Every byte counts.  My real thrust on this is for IoT.  To get IoT developers to build around certs and know their products work with them instead of, well we will get to it eventually.
>
> When I work with 802.15.4 communications with a 128 byte MTU, there is considerable debate over every byte sent.  When you tell an IoT chip maker that they have to go from 32KB memory to 100MB, they walk out of the room.
>
> Oh, I want DOTS and I2NSF developers to be working with certs from the get go, instead waiting for deployments and getting 'production' certs and THEN discovering what works and what does not.  But IoT is in many ways more of a challenge.
>
> So yes, size matters.
>
>>
>>
>> ➢ page was talking about in conjunction with the -CA option. With 'openssl
>>     ca' use of the serial file is mandatory according to the man page.
>>     There are no command line options for it.
>>
>> Fixed in master and will be part of the next releases; the –rand_serial flag.
>>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Using set_serial to control serial number size directly

Jakob Bohm-7
In reply to this post by Robert Moskowitz
On 21/08/2017 16:22, Robert Moskowitz wrote:

>
>
> On 08/21/2017 10:03 AM, Salz, Rich wrote:
>> If the root is going to be trusted, make its serial number be one. ☺
>> Otherwise use eight bytes of random as the serial number, if you
>> follow CABF guidelines.
>
> Kind of where my thinking is going.  But once I make it '1', it might
> as well be 1 byte rand!  :)
>
> Well 1 - 127 random...
>
> But no need to make it 20 octets.  Just leave it at 8. And yes, I can
> see some jump on the 'save' 7 bytes bandwagon.
Note that while the random bits in the serial number are technically
there to defend against attacks on the issuing CA if that CA uses an
old/outdated algorithm, the real issue is retaining compatibility
with Browsers that blindly assume that certificates are created
according to the contractual requirements applied to public CAs such
as DigiCert.

One of those is 20 bytes max (after DER encoding, thus 159 bits max).

Another is at least 64 fresh random bits in each serial number
generated by the CA.

Another may or may not be 20 bytes min (before DER encoding, thus
153 bits min).

> Also why I have to work out BER to compare that sizing to DER. Trying
> to do that today.
BER is never shorter than DER.

However for internal processing in memory-restricted devices, it may be
possible/easy to save space by using a simplified encoding internally,
and then convert to DER on the fly when talking to standard software
(such as Web Browsers) externally.  This will ultimately be a trade off
between code size (to do the conversion) and data size (to store the
certificate).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users