MODSIGN without RTC?

MODSIGN without RTC?

[Alexander Holler]

Hello,

I wanted to try out MODSIGN with kernel 3.7.6 and I've just got hit by:

[    1.346445] X.509: Cert 6a23533cec71c4c52a1618fb4d830e06aa90474e is 
not yet valid

The reason is likely that the (ARM) device in question doesn't have a 
RTC (oh, that topic again ;) ) and gets it's time on boot through NTP.

The used certificate was generated automatically. Having a look at it, 
the following is shown:

        Validity
             Not Before: Feb  6 02:56:46 2013 GMT
             Not After : Jan 13 02:56:46 2113 GMT

Without having thought about possible security problems, my first idea 
would be to let the validity start at 1970. As I never did such I never 
had thought about possible implications when doing such (e.g. I don't 
know if someone checks the start date for plausabilitiy)

Another solution would be to retry loading of the certificate if the 
time gets set (and e.g. differs more than a year).

Has someone already thought about how to solve that problem? Or did 
everyone use sane systems which have a (working) RTC?

Regards,

Alexander

Re: MODSIGN without RTC?

[Alexander Holler]

Am 07.02.2013 00:42, schrieb Alexander Holler:
> Hello,
>
> I wanted to try out MODSIGN with kernel 3.7.6 and I've just got hit by:
>
> [    1.346445] X.509: Cert 6a23533cec71c4c52a1618fb4d830e06aa90474e is
> not yet valid
>
> The reason is likely that the (ARM) device in question doesn't have a
> RTC (oh, that topic again ;) ) and gets it's time on boot through NTP.
>
> The used certificate was generated automatically. Having a look at it,
> the following is shown:
>
>         Validity
>              Not Before: Feb  6 02:56:46 2013 GMT
>              Not After : Jan 13 02:56:46 2113 GMT
>
> Without having thought about possible security problems, my first idea
> would be to let the validity start at 1970. As I never did such I never
> had thought about possible implications when doing such (e.g. I don't
> know if someone checks the start date for plausabilitiy)
>
> Another solution would be to retry loading of the certificate if the
> time gets set (and e.g. differs more than a year).
>
> Has someone already thought about how to solve that problem? Or did
> everyone use sane systems which have a (working) RTC?

Another option would be to make a configure option to just ignore the 
date. I'm not sure if I would like to use MODSIGN when I have to fear 
that the machine wouldn't start when the RTC fails or got set to a wrong 
date.

Regards,

Alexander

Re: MODSIGN without RTC?

[Geert Uytterhoeven]

On Thu, Feb 7, 2013 at 2:06 AM, Alexander Holler <holler@ahsoftware.de> wrote:
> Am 07.02.2013 00:42, schrieb Alexander Holler:
>> I wanted to try out MODSIGN with kernel 3.7.6 and I've just got hit by:
>>
>> [    1.346445] X.509: Cert 6a23533cec71c4c52a1618fb4d830e06aa90474e is
>> not yet valid
>>
>> The reason is likely that the (ARM) device in question doesn't have a
>> RTC (oh, that topic again ;) ) and gets it's time on boot through NTP.
>>
>> The used certificate was generated automatically. Having a look at it,
>> the following is shown:
>>
>>         Validity
>>              Not Before: Feb  6 02:56:46 2013 GMT
>>              Not After : Jan 13 02:56:46 2113 GMT
>>
>> Without having thought about possible security problems, my first idea
>> would be to let the validity start at 1970. As I never did such I never
>> had thought about possible implications when doing such (e.g. I don't
>> know if someone checks the start date for plausabilitiy)
>>
>> Another solution would be to retry loading of the certificate if the
>> time gets set (and e.g. differs more than a year).
>>
>> Has someone already thought about how to solve that problem? Or did
>> everyone use sane systems which have a (working) RTC?
>
>
> Another option would be to make a configure option to just ignore the date.

Or an option to auto-advance the clock to the "Not Before" date if needed...

> I'm not sure if I would like to use MODSIGN when I have to fear that the
> machine wouldn't start when the RTC fails or got set to a wrong date.

Hmm, nice failure mode...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: MODSIGN without RTC?

[Alexander Holler]

Am 07.02.2013 07:42, schrieb Geert Uytterhoeven:
> On Thu, Feb 7, 2013 at 2:06 AM, Alexander Holler <holler@ahsoftware.de> wrote:
>> Am 07.02.2013 00:42, schrieb Alexander Holler:
>>> I wanted to try out MODSIGN with kernel 3.7.6 and I've just got hit by:
>>>
>>> [    1.346445] X.509: Cert 6a23533cec71c4c52a1618fb4d830e06aa90474e is
>>> not yet valid
>>>
>>> The reason is likely that the (ARM) device in question doesn't have a
>>> RTC (oh, that topic again ;) ) and gets it's time on boot through NTP.
>>>
>>> The used certificate was generated automatically. Having a look at it,
>>> the following is shown:
>>>
>>>         Validity
>>>              Not Before: Feb  6 02:56:46 2013 GMT
>>>              Not After : Jan 13 02:56:46 2113 GMT
>>>
>>> Without having thought about possible security problems, my first idea
>>> would be to let the validity start at 1970. As I never did such I never
>>> had thought about possible implications when doing such (e.g. I don't
>>> know if someone checks the start date for plausabilitiy)
>>>
>>> Another solution would be to retry loading of the certificate if the
>>> time gets set (and e.g. differs more than a year).
>>>
>>> Has someone already thought about how to solve that problem? Or did
>>> everyone use sane systems which have a (working) RTC?
>>
>>
>> Another option would be to make a configure option to just ignore the date.
> 
> Or an option to auto-advance the clock to the "Not Before" date if needed...
> 
>> I'm not sure if I would like to use MODSIGN when I have to fear that the
>> machine wouldn't start when the RTC fails or got set to a wrong date.
> 
> Hmm, nice failure mode...

And the dream of every vendor, finally a working expiration date. And a
nice TV-B-Gone, just feed a wrong date once. ;)

Regards,

Alexader

Re: MODSIGN without RTC?

[Alexander Holler]

Am 07.02.2013 08:01, schrieb Alexander Holler:
> Am 07.02.2013 07:42, schrieb Geert Uytterhoeven:
>> On Thu, Feb 7, 2013 at 2:06 AM, Alexander Holler <holler@ahsoftware.de> wrote:
>>> Am 07.02.2013 00:42, schrieb Alexander Holler:
>>>> I wanted to try out MODSIGN with kernel 3.7.6 and I've just got hit by:
>>>>
>>>> [    1.346445] X.509: Cert 6a23533cec71c4c52a1618fb4d830e06aa90474e is
>>>> not yet valid
>>>>
>>>> The reason is likely that the (ARM) device in question doesn't have a
>>>> RTC (oh, that topic again ;) ) and gets it's time on boot through NTP.
>>>>
>>>> The used certificate was generated automatically. Having a look at it,
>>>> the following is shown:
>>>>
>>>>          Validity
>>>>               Not Before: Feb  6 02:56:46 2013 GMT
>>>>               Not After : Jan 13 02:56:46 2113 GMT
>>>>
>>>> Without having thought about possible security problems, my first idea
>>>> would be to let the validity start at 1970. As I never did such I never
>>>> had thought about possible implications when doing such (e.g. I don't
>>>> know if someone checks the start date for plausabilitiy)
>>>>
>>>> Another solution would be to retry loading of the certificate if the
>>>> time gets set (and e.g. differs more than a year).
>>>>
>>>> Has someone already thought about how to solve that problem? Or did
>>>> everyone use sane systems which have a (working) RTC?
>>>
>>>
>>> Another option would be to make a configure option to just ignore the date.
>>
>> Or an option to auto-advance the clock to the "Not Before" date if needed...
>>
>>> I'm not sure if I would like to use MODSIGN when I have to fear that the
>>> machine wouldn't start when the RTC fails or got set to a wrong date.
>>
>> Hmm, nice failure mode...
>
> And the dream of every vendor, finally a working expiration date. And a
> nice TV-B-Gone, just feed a wrong date once. ;)

I've digged a bit around about how to disable the date check, but then 
decided that I shouldn't try to implement that 
(CONFIG_MODSIGN_IGNORE_DATES) because of missing knowledge about the 
(usage of) crypto-api.

I think adding attributes to the key and the parsed key like bool 
ingore_dates and bool parsed_dates_invalid might be an option. Using 
such x509_key_preparse() could just set parsed_dates_invalid instead of 
returning with -EKEYREJECTED or -EKEYEXPIRED, if it encounters invalid 
dates.

Regards,

Alexander

Re: MODSIGN without RTC?

[Olaf Titz]

> Another option would be to make a configure option to just ignore the
> date. I'm not sure if I would like to use MODSIGN when I have to fear
> that the machine wouldn't start when the RTC fails or got set to a wrong
> date.

Or just ignore the date unconditionally. After all, when a certificate
check fails due to out-of-validity-period, then you can always "fix"
that by appropriately setting the clock. So for security, in this
application, the date check is outright useless.

Olaf

Re: MODSIGN without RTC?

[Alexander Holler]

Am 07.02.2013 19:44, schrieb Olaf Titz:
>> Another option would be to make a configure option to just ignore the
>> date. I'm not sure if I would like to use MODSIGN when I have to fear
>> that the machine wouldn't start when the RTC fails or got set to a wrong
>> date.
>
> Or just ignore the date unconditionally. After all, when a certificate
> check fails due to out-of-validity-period, then you can always "fix"
> that by appropriately setting the clock. So for security, in this
> application, the date check is outright useless.

I don't think that is an option, because the date check is part of the 
crypto-api and not a part of the modsign-stuff.

So it's necessary that the crypto-api offers a flag to ignore the dates 
and another flag to mark such keys as invalid because of the date. The 
first flag is necessary to load and use the keys, the second flag for 
(maybe) other users of the crypto-api which might not use such invalid keys.

Regards,

Alexander

Re: MODSIGN without RTC?

[Alexander Holler]

Am 11.02.2013 20:44, schrieb Alexander Holler:
> Am 07.02.2013 19:44, schrieb Olaf Titz:
>>> Another option would be to make a configure option to just ignore the
>>> date. I'm not sure if I would like to use MODSIGN when I have to fear
>>> that the machine wouldn't start when the RTC fails or got set to a wrong
>>> date.
>>
>> Or just ignore the date unconditionally. After all, when a certificate
>> check fails due to out-of-validity-period, then you can always "fix"
>> that by appropriately setting the clock. So for security, in this
>> application, the date check is outright useless.
>
> I don't think that is an option, because the date check is part of the
> crypto-api and not a part of the modsign-stuff.
>
> So it's necessary that the crypto-api offers a flag to ignore the dates
> and another flag to mark such keys as invalid because of the date. The
> first flag is necessary to load and use the keys, the second flag for
> (maybe) other users of the crypto-api which might not use such invalid
> keys.

Another option would be, to just load every key, regardless of the dates 
of the keys, and let the user of the keys (e.g. modsign) decide if they 
accept the dates in the keys.

But I'm missing the big picture about the crypto-api and their users, 
therefor I better don't touch that part of the kernel myself. ;)

Regards,

Alexander

Re: MODSIGN without RTC?

[Alexander Holler]

Am 07.02.2013 08:01, schrieb Alexander Holler:

> And the dream of every vendor, finally a working expiration date. And a
> nice TV-B-Gone, just feed a wrong date once. ;)

Just in case someone missed what I wanted to hint: That date problem has 
implications for devices with a RTC too. If they need too load a kernel 
and signed modules to enable the user to modify the date (of the RTC), 
setting a date outside the range specified in the certificate and 
rebooting will brick such devices.

Regards,

Alexander