RTC Anti-rollback: Difference between revisions
(Working draft - checkpoint) |
(Checkpoint 2) |
||
Line 12: | Line 12: | ||
* RTCAR is performed only in secure mode. |
* RTCAR is performed only in secure mode. |
||
* RTCAR is performed |
* The RTCAR recovery test (see [[#RTCAR Recovery]]) is performed just after the test for firmware update in [[Firmware_security#Process]]. |
||
* RTCAR is performed only if the "ak" tag is not present in [[Manufacturing data]]. |
* The RTCAR boot test is performed only if the "ak" tag is not present in [[Manufacturing data]]. |
||
* The RTCAR boot |
* The RTCAR boot test is performed just prior to the test for a valid lease, i.e. just before step 8 of [[Firmware_security#Process]]. In the presence of rollback or corruption, OFW will boot from actos/actrd. Otherwise it will boot from either runos/runrd or actos/actrd according to the presence or absence of a valid activation lease. In other words, apparent RTC rollback is treated as a missing or invalid lease. |
||
* OFW records the status of the RTCAR check by creating properties in the device tree ''/chosen'' node as follows: |
* OFW records the status of the RTCAR check by creating properties in the device tree ''/chosen'' node as follows: |
||
** Property name: '''rtc-timestamp''' Property value: Null-terminated ASCII string containing the number of timestamps and the value of the most recent preexisting (prior to the current boot) timestamp. The string format is "ccc,YYYY-MM-DD@hh:mm:ss\0". "ccc" is an ASCII decimal number indicating the number of previously-recorded timestamps, with leading zeros suppressed". "YYYY" is the year, e.g. "2011". "MM" is the month number from 01 to 12. "DD" is the day number from 01 to 31. "hh" is the hour number from 00 to 23. "mm" is the minute number from 00 to 59. "ss" is the second number from 00 to 59. The date and time comes directly from the contents of the real time clock registers, with no offsetting or other adjustment beyond conversion from the internal BCD storage format into decimal ASCII. If there is no previously-recorded timestamp, as is the case where the "rtc-status" property contains "empty", the "rtc-timestamp" property will not be present. |
** Property name: '''rtc-timestamp''' Property value: Null-terminated ASCII string containing the number of timestamps and the value of the most recent preexisting (prior to the current boot) timestamp. The string format is "ccc,YYYY-MM-DD@hh:mm:ss\0". "ccc" is an ASCII decimal number indicating the number of previously-recorded timestamps, with leading zeros suppressed". "YYYY" is the year, e.g. "2011". "MM" is the month number from 01 to 12. "DD" is the day number from 01 to 31. "hh" is the hour number from 00 to 23. "mm" is the minute number from 00 to 59. "ss" is the second number from 00 to 59. The date and time comes directly from the contents of the real time clock registers, with no offsetting or other adjustment beyond conversion from the internal BCD storage format into decimal ASCII. If there is no previously-recorded timestamp, as is the case where the "rtc-status" property contains "empty", the "rtc-timestamp" property will not be present. |
||
Line 22: | Line 22: | ||
*** "residue" - the RTC timestamp area contained some data, but there was a problem with it, such as an invalid checksum or junk after the last timestamp. This case is considered as a possible attack, so OFW forces the use of actos/actrd. OFW does not record a new timestamp. The "rtc-timestamp" property may be present or absent, according to whether or not there was at least one valid timestamp. |
*** "residue" - the RTC timestamp area contained some data, but there was a problem with it, such as an invalid checksum or junk after the last timestamp. This case is considered as a possible attack, so OFW forces the use of actos/actrd. OFW does not record a new timestamp. The "rtc-timestamp" property may be present or absent, according to whether or not there was at least one valid timestamp. |
||
*** "rollback" - the RTC timestamp area is valid format-wise, but the most recent timestamp is later than the current RTC time. This case is considered a possible rollback attempt, so OFW forces the use of actos/actrd. OFW does not record a new timestamp. The "rtc-timestamp" property contains the most recent timestamp, i.e. the one that was more recent than the current RTC value. |
*** "rollback" - the RTC timestamp area is valid format-wise, but the most recent timestamp is later than the current RTC time. This case is considered a possible rollback attempt, so OFW forces the use of actos/actrd. OFW does not record a new timestamp. The "rtc-timestamp" property contains the most recent timestamp, i.e. the one that was more recent than the current RTC value. |
||
*** RTCAR Recovery *** |
|||
The RTCAR recovery test permits the repair and recovery of system with an invalid or corrupted RTC timestamp area. OFW will repair the timestamp area if a suitable signed file is present in /security, as detailed below. |
|||
Note that this recovery process *does not* set the RTC value; it only sets the timestamp area. The RTC value must be corrected by other means. |
Revision as of 01:42, 10 May 2011
Purpose
RTC anti-rollback (RTCAR) is a Open Firmware based security feature intended to prevent "RTC rollback attacks" - subversion of timed leases by setting the real-time clock backward in time.
RTCAR works by recording a series of timestamps in SPI FLASH, thus recording the dates and times of recent boots. When starting the OS, Open Firmware compares the current RTC value with the most recent stored value. If the stored value is later than the current value, the RTC is deemed to have been "rolled back" and boots in "activation mode". This limits the effectiveness of rollback attacks.
The series of recorded timestamps is protected from attack by existing lockout mechanisms that prevent the writing of SPI FLASH by any entity other than Open Firmware.
The timestamp storage format is chosen so that the relatively-dangerous operation of erasing a block of SPI FLASH is done only infrequently, only the order of every 6,500 reboots.
OFW Behavior
- RTCAR is performed only in secure mode.
- The RTCAR recovery test (see #RTCAR Recovery) is performed just after the test for firmware update in Firmware_security#Process.
- The RTCAR boot test is performed only if the "ak" tag is not present in Manufacturing data.
- The RTCAR boot test is performed just prior to the test for a valid lease, i.e. just before step 8 of Firmware_security#Process. In the presence of rollback or corruption, OFW will boot from actos/actrd. Otherwise it will boot from either runos/runrd or actos/actrd according to the presence or absence of a valid activation lease. In other words, apparent RTC rollback is treated as a missing or invalid lease.
- OFW records the status of the RTCAR check by creating properties in the device tree /chosen node as follows:
- Property name: rtc-timestamp Property value: Null-terminated ASCII string containing the number of timestamps and the value of the most recent preexisting (prior to the current boot) timestamp. The string format is "ccc,YYYY-MM-DD@hh:mm:ss\0". "ccc" is an ASCII decimal number indicating the number of previously-recorded timestamps, with leading zeros suppressed". "YYYY" is the year, e.g. "2011". "MM" is the month number from 01 to 12. "DD" is the day number from 01 to 31. "hh" is the hour number from 00 to 23. "mm" is the minute number from 00 to 59. "ss" is the second number from 00 to 59. The date and time comes directly from the contents of the real time clock registers, with no offsetting or other adjustment beyond conversion from the internal BCD storage format into decimal ASCII. If there is no previously-recorded timestamp, as is the case where the "rtc-status" property contains "empty", the "rtc-timestamp" property will not be present.
- Property name: rtc-status Property value: Null-terminated ASCII string containing one of the following values:
- "ok" - the RTC timestamp area is valid and the RTC value is more recent than the last timestamp. In this case, OFW will create a new timestamp recording the current RTC value, for use on the next boot. The timestamp that is exported via the "rtc-timestamp" property is the previously-recorded one, not the new one.
- "empty" - the RTC timestamp area was initially empty, i.e. no timestamps were recorded in it. In this case, OFW will automatically initialize the timestamp area and create a new timestamp recording the current RTC value, for use on the next boot. This case is not considered as a "rollback", so OFW will not force the use of actos/actrd. The "rtc-timestamp" property will be absent, as no previously-recorded timestamp information is available.
- "residue" - the RTC timestamp area contained some data, but there was a problem with it, such as an invalid checksum or junk after the last timestamp. This case is considered as a possible attack, so OFW forces the use of actos/actrd. OFW does not record a new timestamp. The "rtc-timestamp" property may be present or absent, according to whether or not there was at least one valid timestamp.
- "rollback" - the RTC timestamp area is valid format-wise, but the most recent timestamp is later than the current RTC time. This case is considered a possible rollback attempt, so OFW forces the use of actos/actrd. OFW does not record a new timestamp. The "rtc-timestamp" property contains the most recent timestamp, i.e. the one that was more recent than the current RTC value.
- RTCAR Recovery ***
The RTCAR recovery test permits the repair and recovery of system with an invalid or corrupted RTC timestamp area. OFW will repair the timestamp area if a suitable signed file is present in /security, as detailed below.
Note that this recovery process *does not* set the RTC value; it only sets the timestamp area. The RTC value must be corrected by other means.