search

linuxboot / heads

A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops, workstations and servers.
https://osresearch.net/
GNU General Public License v2.0
1.42k stars 188 forks source link

How to investigate a TOTP mismatch? #910

Closed Siproqu closed 3 years ago

Siproqu commented 3 years ago

I am looking for some help how I can investigate the cause of TOTP mismatches.

The mismatches occurred after I booted my laptop this morning. This was the first cold boot for 1-2 weeks, before that it has only been in S3. The time was clock was one hour off (which it hasn't been 1-2 weeks before), but even after changing it to the correct time (date -s and hwclock -w etc.) the TOTP still doesn't match.

Any hints how I can start to investigate this before I reflash?

tlaurion commented 3 years ago

@Siproqu Reflashing won't fix since the time difference will persist. (And the time will still not be good). RTC battery being bad?

The problem is probably linked to RTC clock state (hwclock -w) not being saved after having set local clock (date -s '1970-01-01 05:00:00') synced manually with external source on another internet connected device.

Should probably put this somewhere else but here you go for my draft. That should probably be under https://github.com/osresearch/heads-wiki (and http://osresearch.net and a result).

Siproqu commented 3 years ago

I have already set the time with date -s and hwclock -w. hwclock -r returns the correct time after reboot (I have also tried to remove the main battery for 5 minutes to check whether the RPC battery is good - it is). But the TOTP values are still incorrect.

That should probably be under https://github.com/osresearch/heads-wiki (and http://osresearch.net and a result).

Shall I close this one and reopen it on https://github.com/osresearch/heads-wiki?

tlaurion commented 3 years ago

So your firmware was modified?

Siproqu commented 3 years ago

Not that I am aware of. Any chance a Qubes update modified the firmware?

tlaurion commented 3 years ago

Not that I am aware of. Any chance a Qubes update modified the firmware?

@Siproqu : No. QubesOS only modifies /boot components involved in Heads boot components validation which are validated against your GPG public key injected in the ROM, which modifies measurements and requires resealing.

Updating dom0 components (xen, kernel, initrd, grub config) triggers a detached signed (kexec_hashes.txt signed under kexec.sig) discrepancy between what was checksumed and detached signed with private key on USB Security dongle and what is found under /boot at runtime, and invalidates default boot path validation. If combined with Disk Unlock Key released by TPM, bad TPM measurements (PCRs containing different measurements, shown through TOTP different codes) would not permit Disk Unlock Key passphrase to release Disk Unlock Key from TPM NVRAM.

You are sure you didn't inserted a new public key or saved user config changes under Heads? Those are the only moments the firmware should be modified. Of course, if you updated your BIOS, that would also invalidate TPM measurements in PCRs. http://osresearch.net/Keys/#tpm-pcrs

The logic with TOTP is that it is time bounded. So even if you sealed the secret in form of a Qr Code, which you scanned with TOTP app, was from a different time, once you correct RTC clock and the GMT timestamp is the same in TOTP (TOTP is GMT-0/UTC, as Heads) then they should be the same.

Disk Unlock passphrase unlocking your default boot option would confirm that the secret released is valid, and that TPM measurements into PCRs are also valid, leading to understanding why your smartphone is having invalid time.

Theory is that both time sources could be invalid, but it time is good (GMT-0/UTC time, used from Heads and corrected under TOTP app) should have the same TOTP code shown if firmware was not tampered with.

Hope that helps.

Siproqu commented 3 years ago

First of all, thank you very much for you detailed answer!

Now comes the embarrassing part. The initial mismatch of the TOTP was likely because of the time shift. Unfortunately, when I corrected the time I didn't set it to GMT-0. Set it to GMT-0 worked obviously.

@tlaurion Thank you for helping out and sorry that I wasted your time by not reading your post more thoroughly. I'll take some time tomorrow and create a pull request on heads wiki for this kind of issue.

For all the other scatty people who ran into this problem: The TOTP algorithm uses the current _Unix time_ to calculate the next password. And the current Unix time is in 00:00:00 GMT-0/UTC on 1 January 1970. So if you set Heads time to GMT-1 or any other time zone other than GMT-0, it generates passwords for the future or the past. The ppp on your phone will also use GMT-0 to calculate the passwords. Regardless what time zone you are currently in.