* MODSIGN without RTC?
@ 2013-02-06 23:42 Alexander Holler
2013-02-07 1:06 ` Alexander Holler
0 siblings, 1 reply; 9+ messages in thread
From: Alexander Holler @ 2013-02-06 23:42 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MODSIGN without RTC?
2013-02-06 23:42 MODSIGN without RTC? Alexander Holler
@ 2013-02-07 1:06 ` Alexander Holler
2013-02-07 6:42 ` Geert Uytterhoeven
2013-02-07 18:44 ` Olaf Titz
0 siblings, 2 replies; 9+ messages in thread
From: Alexander Holler @ 2013-02-07 1:06 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MODSIGN without RTC?
2013-02-07 1:06 ` Alexander Holler
@ 2013-02-07 6:42 ` Geert Uytterhoeven
2013-02-07 7:01 ` Alexander Holler
2013-02-07 18:44 ` Olaf Titz
1 sibling, 1 reply; 9+ messages in thread
From: Geert Uytterhoeven @ 2013-02-07 6:42 UTC (permalink / raw)
To: Alexander Holler; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MODSIGN without RTC?
2013-02-07 6:42 ` Geert Uytterhoeven
@ 2013-02-07 7:01 ` Alexander Holler
2013-02-07 10:54 ` Alexander Holler
2013-02-13 9:30 ` Alexander Holler
0 siblings, 2 replies; 9+ messages in thread
From: Alexander Holler @ 2013-02-07 7:01 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MODSIGN without RTC?
2013-02-07 7:01 ` Alexander Holler
@ 2013-02-07 10:54 ` Alexander Holler
2013-02-13 9:30 ` Alexander Holler
1 sibling, 0 replies; 9+ messages in thread
From: Alexander Holler @ 2013-02-07 10:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel, Herbert Xu, David Miller, Rusty Russell, David Howells
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MODSIGN without RTC?
2013-02-07 1:06 ` Alexander Holler
2013-02-07 6:42 ` Geert Uytterhoeven
@ 2013-02-07 18:44 ` Olaf Titz
2013-02-11 19:44 ` Alexander Holler
1 sibling, 1 reply; 9+ messages in thread
From: Olaf Titz @ 2013-02-07 18:44 UTC (permalink / raw)
To: linux-kernel
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MODSIGN without RTC?
2013-02-07 18:44 ` Olaf Titz
@ 2013-02-11 19:44 ` Alexander Holler
2013-02-12 13:00 ` Alexander Holler
0 siblings, 1 reply; 9+ messages in thread
From: Alexander Holler @ 2013-02-11 19:44 UTC (permalink / raw)
To: Olaf Titz
Cc: linux-kernel, Herbert Xu, David Miller, Rusty Russell, David Howells
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MODSIGN without RTC?
2013-02-11 19:44 ` Alexander Holler
@ 2013-02-12 13:00 ` Alexander Holler
0 siblings, 0 replies; 9+ messages in thread
From: Alexander Holler @ 2013-02-12 13:00 UTC (permalink / raw)
To: Olaf Titz
Cc: linux-kernel, Herbert Xu, David Miller, Rusty Russell, David Howells
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MODSIGN without RTC?
2013-02-07 7:01 ` Alexander Holler
2013-02-07 10:54 ` Alexander Holler
@ 2013-02-13 9:30 ` Alexander Holler
1 sibling, 0 replies; 9+ messages in thread
From: Alexander Holler @ 2013-02-13 9:30 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel, Herbert Xu, David Miller, Rusty Russell, David Howells
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-02-13 9:30 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-06 23:42 MODSIGN without RTC? Alexander Holler
2013-02-07 1:06 ` Alexander Holler
2013-02-07 6:42 ` Geert Uytterhoeven
2013-02-07 7:01 ` Alexander Holler
2013-02-07 10:54 ` Alexander Holler
2013-02-13 9:30 ` Alexander Holler
2013-02-07 18:44 ` Olaf Titz
2013-02-11 19:44 ` Alexander Holler
2013-02-12 13:00 ` Alexander Holler
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.