Unix timestamps from Xous and the RTC

[blakesmith]

Hi all,

I'm interested in porting a TOTP / MFA RFC6328 one-time password generator to Xous & Betrusted. My current plan is:

• Use the HMAC gateware for passcode generation when the algorithm variant is HMAC-SHA256 or HMAC-SHA512. I'll still need a software fallback for HMAC-SHA1, since the OpenTitan HMAC core we're using understandably doesn't appear to have SHA1 support (most TOTP vendors such as Google Authenticator still befault to 30 second HMAC-SHA1 one-time passwords, so still need to support it).
• Use the rust port of flatbuffers for persisting secrets and TOTP configuration in pddb. I've already confirmed that flatbuffers is compiling cleanly against the xous Rust target, but haven't had time to do any runtime testing (yet). More to come here.

The one thing I need to figure out is how to get a Unix timestamp from Xous / the RTC to compute the one-time password. A few things I've researched:

• To accurately calculate a unix timestamp, I believe I need to know what timezone the user is in so I can do any zone shifts from GMT. I dug around a bit in the datasheet for the RTC (I couldn't find a precise BOM for the Betrusted, so this was just based on a google from chip identifiers in the Betrusted guided tour Feb 2022 image), and I don't believe the RTC tracks any concept of time zones.
• The RTC time interface in Xous also seems to be timezone agnostic. It looks like it's a simple wrapper around the underlying register set from the RTC.

I'd like to have Xous handle timezones, but haven't dove deep enough into things like a tz database yet to understand the implications of bringing something like this into scope for Xous. I'd also want to think through any more attack surface area of timezone manipulation. I'm also not sure which Xous service would be responsible for TZ relevant operations.

Before I go too deep down the rabbit hole, I'm looking for some high level feedback on direction:

1. Should Xous track / handle timezones? It seems like a basic service that many applications are going to need.
2. If so, are there any considerations I should keep in mind (Security risks, threat models, Xous interfaces, correct tz database handling, etc.)

Curious to hear any feedback or thoughts. Thanks!

[bunnie]

Wow. #TIL there is a discussions tab in github.

RTC is literally one of the things on the plate right now between me and @xobs. Tonight I am going to take a whack at figuring out what it takes to integrate our hardware into the libstd RTC target, so I'm going to learn a lot more about your question soon.

As far as time zones, this has weighed on my mind quite a bit. The key problems in my mind are:

1. Timezone databases are big. I just did a quick check and one site is offering a CSV of them weighing in at around 950k. For comparison, the full Xous image is about 6MiB, the loader and fonts are about 1.5MiB.
2. Timezone databases are constantly changing. And, we don't really have an autonomous on-line update mechanism in place yet (right now you have to use a host to load firmware, ideally, we can get to a point where we're downloading files via wifi and applying the patches directly).

So, in a nutshell, I think Xous should have TZ handling, but I don't understand enough about who uses it to make an informed decision about how to architect this.

Some questions I actually have for your TOTP / MFA application:

1. Do you just need the time zone setting for your local time zone, or do you need to be able to calculate offsets from arbitrary remote timestamps?
2. What do TOTP / MFA apps do today about changes to TZ policies?

If it's the case that you basically just need your local time zone (or maybe two or three other TZs that you travel to), one viable method might be to store the TZ data in the PDDB.

If it's the case that really you need to be able to look up offsets to a server that might happen to be located anywhere in the world, then, we would need to store the entire TZ database inside Xous. In which case, I would advocate to integrate it into the loader image. The loader has a block of memory that is signed but unencrypted and meant for large, static datastructures that change infrequently. For example, the font data is in the loader, not the kernel. This is important in part because for now the kernel is 100% running out of RAM, so every bit of static data we load into RAM is less RAM for applications; and it also takes pressure off the RAM L2 cache because the loader region is uncached but actually quite fast to access for sequential reads due to a quirk of our architecture.

The main downside of putting TZ data into the loader is it reduces the space available for future fonts. We have 4.3MiB allocated for fonts, of which 1.06MiB are used right now to hold Emoji, Chinese, Japanese, Korean, Bold, mono, regular, and small typefaces. This means we're missing things like Cyrillic, Arabic, Tamil, Hindi, Hebrew, Thai, Mongolian, etc. etc. We reserve a huge amount of space becauses some of the languages, such as Arabic and Tamil, have complicated rules to compose characters could be eased by storing large tables of pre-composed letters, but I haven't researched this enough to really have a grasp of exactly how much space we'd need and what the best practices are to support these.

However, "burning" about 1MiB on a time zone table would mean we still have about 2MiB free, which given the density of our Chinese and Japanese encodings I'm optimistic it could be enough to support quite a few more languages before we run out of space. So I'm not against the idea of putting a full TZ table into Xous, but if there were a binary encoding that was more compact than CSV that could reduce its footprint to a few hundred kiB that would make it a done deal.

Again, a lot of open questions, and something I really don't understand well enough to answer. Another question I haven't figured out yet but soon well is if libstd is supposed to handle TZ natively, or if it punts to the OS for that. If it's punted to the OS, it frees us up to only download the TZ descriptors for the zones we care about; if it's baked into libstd then that virtually forces us to have the entire table resident, because otherwise we'd be breaking some libstd APIs.

Anyways, sorry this isn't so conclusive, but if you can share any insight with me or thoughts about what is the right direction to take this, I am optimistic we can find the right trade-off between code size, usability, and sustainability.

Oh finally, from the security side, I'm assuming that so long as the TZ formats are signed for distribution (but not encrypted) we're good. However, if there are security protocols that are irreparably broken if someone can shift a TZ definition without us noticing, then actually we need to rethink a lot of this, because it's not just about code distribution, we have to question the actual source TZ databases themselves. From a cursory inspection, a lot of the source TZ databases are community maintained and they could be a vector for a supply chain attack, where someone poisons the TZ definition at the source.

[xobs]

I think this may be a good impetus to get flat MiniELF implemented, since it would be a good place to store that database.

[blakesmith]

Thanks @bunnie. Responses inline.

RTC is literally one of the things on the plate right now between me and @xobs. Tonight I am going to take a whack at figuring out what it takes to integrate our hardware into the libstd RTC target, so I'm going to learn a lot more about your question soon.

Glad to hear you're thinking about the time interfaces!

Do you just need the time zone setting for your local time zone, or do you need to be able to calculate offsets from arbitrary remote timestamps?

For my specific use-case, I actually just need a stable unix timestamp. So, in pure Rust form, with the standard library on another OS, it'd be as basic as:

use std::time::{SystemTime, UNIX_EPOCH};

fn get_timestamp() -> Result<u64, Error> {
    SystemTime::now().duration_since(UNIX_EPOCH).map(|duration| duration.as_millis())
}

My (perhaps incorrect) assumption was that in order to calculate a Unix timestamp, the OS would at a minimum need to know the user's Timezone (since they'll be setting their Betrusted system RTC time in their 'local zone'), and then be able to shift it to GMT, since Unix timestamps are always calculated from GMT. I haven't read through Linux or any other OS's implementation of how it calculates a unix epoch yet to know if there are tricks or implementation methods that I'm missing.

What do TOTP / MFA apps do today about changes to TZ policies?

In my case, most implementations assume there's an OS that can give you a stable timestamp. Here's a very basic totp library I've used to implement a TOTP client as a desktop application before, if you want to take a look at the details. I wonder if most hardware TOTP token generators (RSA keys, for example) use a GPS sync'd clock or something. Not sure what techniques other hardware-implementations of TOTP use.

So I'm not against the idea of putting a full TZ table into Xous, but if there were a binary encoding that was more compact than CSV that could reduce its footprint to a few hundred kiB that would make it a done deal

+1 on finding some binary encoded format of tzdata: This feels like it must be a solved problem with some prior art, but I'm not sure about specifics. There has to be other embedded targets that don't want to store a plaintext CSV. I wonder how small this could get down to?

Another question I haven't figured out yet but soon well is if libstd is supposed to handle TZ natively, or if it punts to the OS for that.

I dove through the Rust std implementation for std::time, and it's pretty minimal. You'll have to double check me in some of your research, but my understanding is that the stdlib punts most timezone handling to the operating system via libc calls. For example, SystemTime::now from Rust just bottoms out at a gettimeofday call in Linux. I think the basic assumption is that the OS will handle all that for you. For more complex Date / Time handling, most of the Rust community leverages crates such as chrono, and other variants.****

[xobs]

Chrono should be possible to integrate, though you'd need to fork it to get an sys module. You probably could do whatever wasi does.

[bunnie]

I would assume that RSA keys just have a crystal that tracks time, and that an offset relative to real time is programmed in once at the factory. Actual synchronization to GPS network or what it says on the wall clock isn't the name of the game, it's tracking increments of time since a fixed offset, with low drift. I hadn't taken one apart myself but based on the cost, size, and battery available to the devices, and the fact that they have to operate indoors, GPS would be ruled out, and the fact that they operate even if you hop on a plane and go somewhere else, synchronization to terrestial radio clocks is also ruled out. Probably there's a spec out there but if I were the system architect I'd just define a +/-ppm stability band for the crystal and then compensate for crystal drift over time by observing if a user entered a timestamp that is one quantum in the future or in the past and apply a "leap second" algorithm to account for that, if you need stability better than the average ppm of a crystal can deliver.

That being said, it looks like from your spec actually the time zone isn't as important as having the RTC run with same settings all the time. So this points to it being more complicated if you program the RTC hardware to be set to the local time zone, because if you change time zones then your hardware time would gain or lose as many seconds as the time zone change would indicate.

In which case, probably what should happen is the RTC should actually be programmed in UTC and stay in UTC; and then the UX would translate UTC to a local time zone through a time zone database. That way if you shift time zones, the hardware itself doesn't gain or lose seconds. The wall-clock time is just a layer of gloss applied on the underlying time as a UX trick, and thus as easily patched as adjusting a TZ offset without messing with the cryptographic properties of the system.

The RTC hardware is also a little bit weird in that it's actually more like a watch than a counter; it keeps track of dates and times in BCD and also tracks a day of week, and its resolution is limited to exactly 1 second. It's also weird in that the RTC has an API to set its time, but the Ticktimer deliberately does not, so in some ways the Ticktimer is more tamper-resistant.

So the thought on how time would actually work is system time would compute with the following algorithm:

0. Initially, the RTC is marked as "unitialized", and time is unsuitable for use for e.g. TOTP transactions. I don't know if there is a way to indicate this in the current API, but, definitely, the RTC is totally invalid when you receive the system.
1. Once the RTC is initialized with a UTC time, it in theory should never be adjusted again (altho we have to consider what happens in case of clock drift -- maybe there is a way to handle that, but for now, let's say it gets set to UTC and never changed, and once we get NTP going or something we can code in leap seconds)
2. On power-up or resume, the current time as indicated by the RTC is read into an offset register
3. Time is tracked as offset in ticks (milliseconds) from the most recent RTC time snapshot, and this is what is returned by e.g. a duration_since() type of call
4. Before going to sleep, the RTC value is stashed somewhere in persistent memory as a sanity check
5. If the RTC value is observed to go backwards or otherwise fail validation after resume (it is actually capable of returning nonsense times like 26 o'clock and 72 minutes, because it is BCD) (the clock also has a glitch detector, so this would be a validation failure too), we return to step 0.
6. For user-friendly local time, a TZ mapping would be needed to turn UTC into wall clock time. I would say that since this mapping isn't critical to the TOTP application, let's start by fudging this as something the user just enters -- like, OK, it's 8PM here in Singapore but noon UTC, and you just accept that to be reality -- and then later on once we get something like an NTP or what not in place we can get more sophisticated and layer in TZ databases and what not.

This also means we aren't putting e.g. MiniELF in the critical path of getting RTC. I sorely want a MiniELF format, but I also think we can transparently work through improving the TZ handling in an incremental fashion, rather than trying to bite off the entire chunk of NTP + TZ + RTC + MiniELF before we can do a TOTP thing. This is of course all premised on my observation that all TOTP really seems to need is a true relative time since an absolute starting point. If I misunderstood that, then, I would need to rethink this conclusion.

[blakesmith]

@bunnie I really like the approach you've laid out. I didn't realize the RTC had second level resolution for dates and times, so I think you're right that Ticktimer will have to come into the mix somehow.

One other question: How are you all planning on managing user locales / languages? Perhaps it'd make sense to store a user's selected timezone in the same "user settings" kind of Xous service where we'd store core settings like a user locale, or perhaps currency display preferences, and any other future user-specific settings, etc. Just an idea I had!

That being said, it looks like from your spec actually the time zone isn't as important as having the RTC run with same settings all the time. So this points to it being more complicated if you program the RTC hardware to be set to the local time zone, because if you change time zones then your hardware time would gain or lose as many seconds as the time zone change would indicate.

I would say that since this mapping isn't critical to the TOTP application, let's start by fudging this as something the user just enters -- like, OK, it's 8PM here in Singapore but noon UTC, and you just accept that to be reality

Yes, that sounds good. If Xous can provide a stable Unix timestamp, there's no need to do any Timezone operations up in (this) user application. There might be other use-cases that need to do timezone shifting / operations, but I imagine that can come later once more of the time-related APIs and system services for time are fleshed out.

Here's my plan of approach, let me know what ya'll think:

1. I'll start roughing out my implementation, get all the UX, graphics, and integration with the HMAC core going.
2. I'll set my local Betrusted clock to UTC for testing, and do some kind of temporary solution in the application for converting from the RTC clock readings to a timestamp.
3. I can share the implementation here, and see where ya'll are at with the Xous side. I'm happy to lend a hand towards implementation inside Xous, if that'd be useful.

[bunnie]

Locales are tricky. We statically compile the translated strings into the binary to keep things compact -- otherwise we end up in a kind of a nightmarish all-strings-in-binary situation, where the translations take up a huge amount of static space.

So, the current mea culpa is I'm opting for a worse experience selecting locales in exchange for trimmed down binary size and simplicity of locale management: that is, you pick your language when you update your device. If you run the update scripts, they will spit out a help message that tells you how to change your locale during the update.

The running theory is that your preferred language is your preferred language for the UX. Picking a language for the UX does not eliminate the other fonts: you can still render messages in foreign languages. It's just that your default warnings and dialogs come up in your native tongue.

On the other hand, people change TZs all the time, without changing their language setting. So, I think having a dynamically changeable TZ setting is going to be the direction we have to take this. I am not sure how we're doing to do the TZ setting game, but, probably taking a page from e.g. the Linux shell based install screens, probably a two or three-level hierarchical menu that goes by continent, possibly region (defining regions is tricky tho with politics these days), and then by major city is the way to go. But I think this is probably a bridge to burn much later on once we have a TZ system to speak of, initially, it may just be some cringey "please type your nearest major city and hope it matches" sort of thing.

I just finally managed to replicate @xobs libstd build environment, and got nerd-sniped along the way to convert the loader into a monorepo, so I am just finally getting around to looking at the actual API functions. In other words, I'm working on it, but, since this is my first attempt to tweak something in libstd it may be slow going.

[bunnie]

@blakesmith I'm trying to think through the initial time setting process while reading through this RTC chip's datasheet in more detail. Something I'm realizing and slightly regretting is that this RTC chip is kind of the worst of all worlds. What I really want is just a counter that counts seconds, but what I have is a chip that does some bookkeeping on seconds to convert them into hours, minutes, seconds, days, weeks, years, with some dodgy leap year algorithm that just does divisible-by-4 plus '00 but not accounting for the divsible-by-400 rule (I guess in practice it's probably fine but I would have preferred just a count of seconds).

Cut to the chase, how do you feel about this policy for Precursor:

• There is no time zone until the PDDB is initialized (because you need the PDDB to store it). But I presume you need the root keys and the PDDB to also store e.g. TOTP secrets and what not, so your TOTP timer wouldn't be able to start anyways until the PDDB is init'd.
• On PDDB init, a key is stored which indicates that the RTC was set, along with its last known value (as an monotonicity check), and the TZ is bogus which means your date and time will probably start at Unix epoch (Jan 1 1970).
• The actual value stored in the hardware RTC is Unix epoch, and it never changes. A function is provided that essentially converts the BCD output of the RTC into "seconds since PDDB was initialized" plus some fixed but random offset of between 0-10 years (just to minimize the deniability leak with respect to the absolute age of the PDDB).
• We don't use the weekdays register in the hardware RTC, as it is basically just modulo-7 counter and doesn't meaningfully add to our knowledge of time; instead we extract weekdays using a more comprehensive/complete coding in software.
• When the user "sets time", what is actually computed is the difference in seconds between Epoch and the current time, and from there on forward, the user-friendly rendered time is computed using that difference. That difference in seconds is also stored in the PDDB.

In this scheme, you can start using your TOTP app before you have set your "real time offset" from the hardware RTC, as long as you use Instant. I was just checking the Rust manual, and it says that SystemTime is not guaranteed to be monotonic, but Instant is, so I think in your code example, maybe it should use Instant instead:

use std::time::{Instant};

fn get_timestamp() -> Result<u64, Error> {
    Instant::now().duration_since(Instant::zero()).map(|duration| duration.as_millis())
}

SystemTime seems it could drastically shift when users decide to change their TZ, whereas Instant is independent of that.

Does this jive with what you're thinking? I think the TL;DR is:

• You OK to use Instant instead of SystemTime?
• You OK to have TOTP function not stable/guaranteed until user has initialized the PDDB?

[blakesmith]

Thanks for digging more on this @bunnie

What I really want is just a counter that counts seconds, but what I have is a chip that does some bookkeeping on seconds to convert them into hours, minutes, seconds, days, weeks, years, with some dodgy leap year algorithm that just does divisible-by-4 plus '00 but not accounting for the divsible-by-400 rule (I guess in practice it's probably fine but I would have preferred just a count of seconds).

That makes sense. The hardware RTC interface makes it seem like it's more meant to be used directly in an environment without an OS translation layer in the mix. From your post, it sounds like you still have an RTC that you can "fix in software" though? 😁

But I presume you need the root keys and the PDDB to also store e.g. TOTP secrets and what not, so your TOTP timer wouldn't be able to start anyways until the PDDB is init'd.

Yes, I think this coupling makes sense for my use-case. The first thing I already started doing last night was roughing out an initial integration with PDDB, trying to store the TOTP secrets as serialized flatbuffers. So, that is to say: PDDB is already a hard dependency of my app, because of the secrets involved. One question I have though: If someone wanted to make a simple 'unix epoch desk clock' application on the Precursor (where they just want to interact with the RTC and display it in some graphical format, no secrets), does that imply that they'd also have to utilize the PDDB APIs as well to wait for it to be initialized, or would they just get bogus time values from an Instant::now call until it's initialized? I believe the clock widget in the top-right corner of the screen would be affected by this as well.

one surprising consequence of the architecture is you are free to poke around without unlocking the PDDB. So in theory someone could try to start the TOTP app and do something, but whatever they did would not make sense because you'd have no secrets accessible.

I think that's fine. We need the PDDB to be mounted / accessible to list and access secrets, and we need the clock to be stable. After that, it's off to the races. I can even use the existing PDDB#is_mounted / is_unlocked style calls to prompt the user to unlock the PDDB before trying to display secrets and computed TOTP psswords. On the RTC side of things: Nothing about computing the TOTP passwords will actually fail / crash with wrong timestamps, the user will just get incorrect password values until they properly set their clock. If there's some API to call that can indicate whether the clock has been initialized by the user (like you hinted at), then I can eventually show some sort of warning to the user that they need to set their clock before passwords will compute correctly. For the first pass on the UX and prototyping, I'll probably just skip this kind of thing and have a static warning somewhere on the screen, so it's a "nice to have" from my perspective, not a "must have" for a first pass.

You OK to use Instant instead of SystemTime?

Yup, that works great. I like that Instant is monotonic, if you can mostly guarantee that from the RTC / Xous libstd implementation. Most servers that accept 2FA / TOTP passwords have to already program in "clock skew" to accept values a generation or two older / newer, for UX, and the speed of the user typing in passwords anyways. So, I actually think this is a perfect use-case for Precursor (even before an NTP sync implementation over Wifi). You already have to round to the nearest clock / step generation on the device, and in some cases the latest 2-3 generations on the server side, so even the monotonic guarantees can be relaxed (though other later users of the Instant interface might need stronger monotonic guarantees down the line).

You OK to have TOTP function not stable/guaranteed until user has initialized the PDDB?

Sounds good. For a very rough first UX, I'll probably start with something clunky, and show a static warning to the user that they need to properly set their clock before passwords compute correctly. I also have a lot I need to figure out about how to actually get the secret values safely into the Precursor. I'm going to start with the most basic, and just make the user type them in, since the most paranoid people are probably going to want that as a fallback anyways. Most vendors seem to issue between 16-32 character base32 encoded secrets, so it's not completely unreasonable to have those typed in on the keyboard. Might be cool to have some simple / easy to audit and inspect way to load secrets into PDDB over the USB interface down the line.

So, the remedy is the TOTP app will need to pause its startup until the PDDB is mounted. I have an example of how to do that in the connection_manager inside the status server.

I'll take a look tonight, thanks!

[bunnie]

I just added this API call for you:

xous-core/services/pddb/src/lib.rs

Line 106 in b50dbf0

pub fn is_mounted_blocking(&self, poll_interval_ms: Option<u32>) {

The usage is something like this:

            let pddb = pddb::Pddb::new();
            pddb.is_mounted_blocking(None);

Where if you specify Some(u32) as the argument you can specify a poll time in ms but otherwise it picks a random interval between 1 and 2 seconds to check.

I like having a bit of randomness in these mass-synchronization polls where several processes can be triggered by an unblock just so the thread scheduler generally avoids a mode where everything gets lined up on an integer-second instant to check for a condition, but you can override that and specify your own interval if you prefer.

[blakesmith]

This is exactly what I (didn't realize) I needed. When I was trying to do operations against PDDB in the simulator, it was hanging up on an "Incorrect Password" prompt, and not allowing me to access the main top level menu. Now, the process is just blocking in the background.

One question for ya'll: Is there a way to Initialize Root Keys in the simulator, to actually test PDDB operations with keys, or should I just stick to testing on device?

Thanks again!

[bunnie]

If you are referring to hosted mode, comment out this line:

xous-core/services/pddb/src/main.rs

Line 471 in b50dbf0

#[cfg(not(any(windows, unix)))] // skip this step if running in hosted mode

This will cause the system to auto-init a fresh PDDB every time on boot. I don't have a way yet to specify "use this file as the backing for the PDDB" but it's something on the list of things to add. I suspect it would be just a couple hours of effort to get it integrated and tested, so it's not a big deal and others will probably need it to -- just a matter of juggling priorities. If you could use that feature let me know. Otherwise, the way I have been testing it is a test stub that just writes in a set of pre-defined keys using a snippet something similar to this:

xous-core/services/pddb/src/main.rs

Lines 1197 to 1253 in b50dbf0

	#[allow(dead_code)]
	pub(crate) fn manual_testcase(hw: &mut PddbOs) {
	log::info!("Initializing disk...");
	hw.pddb_format(true, None).unwrap();
	log::info!("Done initializing disk");
	// it's a vector because order is important: by default access to keys/dicts go into the latest entry first, and then recurse to the earliest
	let mut basis_cache = BasisCache::new();
	log::info!("Attempting to mount the PDDB");
	if let Some(sys_basis) = hw.pddb_mount() {
	log::info!("PDDB mount operation finished successfully");
	basis_cache.basis_add(sys_basis);
	} else {
	log::info!("PDDB did not mount; did you remember to format the PDDB region?");
	}
	log::info!("size of vpage: {}", VPAGE_SIZE);
	// add a "system settings" dictionary to the default basis
	log::info!("adding 'system settings' dictionary");
	basis_cache.dict_add(hw, "system settings", None).expect("couldn't add system settings dictionary");
	basis_cache.key_update(hw, "system settings", "wifi/wpa_keys/Kosagi", "my_wpa_key_here".as_bytes(), None, None, None, false).expect("couldn't add a key");
	let mut readback = [0u8; 15];
	match basis_cache.key_read(hw, "system settings", "wifi/wpa_keys/Kosagi", &mut readback, None, None) {
	Ok(readsize) => {
	log::info!("read back {} bytes", readsize);
	log::info!("read data: {}", String::from_utf8_lossy(&readback));
	},
	Err(e) => {
	log::info!("couldn't read data: {:?}", e);
	}
	}
	basis_cache.key_update(hw, "system settings", "wifi/wpa_keys/e4200", "12345678".as_bytes(), None, None, None, false).expect("couldn't add a key");
	// add a "big" key
	let mut bigdata = [0u8; 5000];
	for (i, d) in bigdata.iter_mut().enumerate() {
	*d = i as u8;
	}
	basis_cache.key_update(hw, "system settings", "big_pool1", &bigdata, None, None, None, false).expect("couldn't add a key");
	basis_cache.dict_add(hw, "test_dict_2", None).expect("couldn't add test dictionary 2");
	basis_cache.key_update(hw, "test_dict_2", "test key in dict 2", "some data".as_bytes(), None, Some(128), None, false).expect("couldn't add a key to second dict");
	basis_cache.key_update(hw, "system settings", "wifi/wpa_keys/e4200", "ABC".as_bytes(), Some(2), None, None, false).expect("couldn't update e4200 key");
	log::info!("test readback of wifi/wpa_keys/e4200");
	match basis_cache.key_read(hw, "system settings", "wifi/wpa_keys/e4200", &mut readback, None, None) {
	Ok(readsize) => {
	log::info!("read back {} bytes", readsize);
	log::info!("read data: {}", String::from_utf8_lossy(&readback));
	},
	Err(e) => {
	log::info!("couldn't read data: {:?}", e);
	}
	}
	}

(but you can skip the initialization since it's already been initialized).

If you're running in Renode, I think @xobs has a way to save out the PDDB file but I don't know what it is.

[bunnie]

btw, hosted mode has sprouted a semblance of a persistent PDDB. It creates a disk image in tools/pddb-images/hosted.bin, it will eat 100MiB of your disk whether you like it or not (sorry!).

It is very lightly tested.

[xobs]

The concept of Instant is that it is roughly equivalent to a system's uptime. When the system reboots, it will go back to zero.

The situation you're describing with SystemTime seems remeniscent of the 1980s IBM PC which had a fancy RTC chip and caused Dos and Windows to use localtime for system time.

Since then, most platforms have opted to store an epoch of some sort in the RTC and do adjustment in the OS, which would be ideal if we could get timezones right.

It could just be as simple as having a setting to set the timezone offset that the user has to manually adjust. The RTC time would always be in terms of UTC, but the time presented to the user would be adjusted by the timezone offset. They'd have to manually adjust it twice per year in the case of daylight saving, but perhaps that could work?

Looking at events in the past would be weird though, since they'd be off by an hour. But looking at events in other timezones is always weird anyway, so I'm not sure if that's a problem or not.

[bunnie]

The RTC retrofit is bigger than I had expected, so I am turning it into a check list of things such that I don't forget something.

1. Remove existing RTC calls. They are wrong.

• strip out legacy RTC server
• strip out RTC test functions
• comment out RT reporting in status (fill in dummy string)

2. Integrate new unprivileged RTC calls into llio crate:

• read physical RTC value in seconds. Interpreted as seconds since initialization, where the smallest possible date is "00:00:00 on 1/1/00" in the RTC's BCD coding. Basically, we use the RTC as just a second-counter, 0-offset from initialization. This allows the system to "work properly" for over 90 years from the point at which the RTC was first initialized.
• set wakeup alarm as delta offset seconds in the future

3. Reduce number of registerable I2C callers allowed to 2 (codec and rtc), down from the current 3 (codec, and rtc). We don't need a separate registerable I2C for llio because it already has the address of the I2C server, given that the I2C is a child of llio.

4. Build the RTC server anew inside the status crate. We locate it here because the status crate already has all the requisite dependencies, and we don't want to build a full separate server for the RTC function as we want to keep the memory footprint down.

5. Implement the following private RTC functions. These are not callable from any other crate:

• validate RTC. This checks if the glitch detector is set, and if the BCD values are well-formed.
• initialize RTC. Picks a random number between 3x10^7 seconds and 3x10^8 seconds (1 and 10 years), and forces it into the RTC. The random number is used to make it harder to prove how long a device has actually been used, in case it matters for deniability. Usually only called if validate RTC fails, or if the PDDB keys did not exist before. An initialization call also notes if it happened by setting the init_happened flag. If the PDDB happens to be mounted, delete the .System:sys.rtc.monocheck key.
• initialize PDDB records. Create and set .System:sys.rtc.monocheck with the current RTC offset. Clears init_happened flag.
• monotonicity check RTC. This compares the RTC value against prior stored value in the PDDB at .System:sys.rtc.monocheck for monotonicity. Always called on resume, but can be called at other times if desired.
• snapshot on sleep. Takes the RTC value and writes it to .System:sys.rtc.monocheck.
• Update SessionOffset. Reads the RTC value in seconds and stores it along with the simultaneous ticktimer value. These two values form the SessionOffset struct. This is always called on boot, resume, and after first initialization.

6. Implement the following unrestricted public RTC functions. These are used by libstd to implement Instant and SystemTime:

• session_offset() - retrieves the at-boot recorded RTC value and elapsed time (ticktimer in ms)
• valid() - returns a bool indicating if the time is valid and has passed checks.

Valid is false under the following conditions:

• init_happened is set. Normally this is cleared when PDDB records are written; so if it is set, it indicates that the RTC failed validation and was set to a new random offset.
• RTC or ticktimer failed a monotonicity check.

7. Implement libstd routines

• Instant uses ticktimer.elapsed_ms() to derive Instant::now(). Instant::zero is just 0. This can work even when the PDDB is not initialized.
• SystemTime uses uses the session_offset() and ticktimer.elapsed_ms()plus the PDDB.Sysetm:sys.rtc.offset` parameter to return a system time. If the PDDB key is not set, it will assume an offset of 0 and you'll get something weird for the current time.

Summary of PDDB keys:

• .System:sys.rtc.monocheck the last known RTC reading in seconds, usually saved on suspend
• .System:sys.rtc.tz: the offset in seconds between UTC and the current time zone. Used to generate the current "display time", outside of libstd. This key would eventually be replaced with a proper TZ database and/or a chrono crate or something like that.
• .Sysetm:sys.rtc.offset: the offset in seconds between the RTC reading and UTC. Relies on .System:sys.rtc.tz being correct. Used by the SystemTime routines.

Expected user experience:

• On boot, Instant works (but valid() is false, because we haven't set the PDDB backing records), but SystemTime will seem to return a strange arbitrary time, sometime between 1971 and 1981. Attempts to use Instant are valid until the PDDB is initialized, at which point the base RTC time is reset to an arbitrary point. So basically, avoid relying on monotonic time if valid() is false.
• Once the PDDB is initialized, valid() will return true and Instant works, but SystemTime continues to be broken. TOTP implementations that rely exclusively on Instant will work, even if the time zone and UTC offset are specified later.
• Only once user fills in a UTC +/- hrs dialog box and a current time dialog box sequence, will the actual "real time" seem to make sense, but as mentioned above, this does not impact the correctness of Instant.

[bunnie]

Right, I added a note to my comment after the fact that you will need the custom version of libstd for the branch to work and it's not easy to build it. I think the changes are small enough that it's worth me trying to push a new version just to learn how hard it is to coordinate on this dance.

So - try the following:

• rm -r -target: removes intermediates built using the old libstd
• cargo xtask install-toolkit --force: grabs the latest libstd and installs it. The --force is important.
• run your build command and test

You should not need to reformat the PDDB to get things to work, all it uses the PDDB for is to store a couple of keys, but if you do get stuck in a bad state on the PDDB please open a bug and instructions on how to reproduce. I did encounter a truncated dictionary entry for example because I wasn't flushing the caches to disk fast enough, and I rebooted the device. That particular problem should be patched now, but certainly there will be more...

[bunnie]

Fyi this is the version of libstd you should be using to get time support, if you're manually installing: https://github.com/betrusted-io/rust/releases/tag/1.59.0.3

Again, 80% of the mechanism for time is actually in Xous not in Rust (I think this is the same for other platforms since they rely on libc to do the time zone heavy lifting) -- so you have to be on bunnie-dev branch for it to work. That being said, I think that's the right call to not put too much complexity into libstd because it's such a disruptive event for devs to push and re-install it. I'm willing to be told I'm wrong about that.

[bunnie]

Ok I got through an initial pass of comprehensive testing and fixed a few bugs, but I have discovered at a fairy late stage that suspend/resume got borked somehow, and also, there is something that is pegging the CPU but I can't quite figure out what (I think the two are linked -- seems like something is in a busy wait loop). I was hoping to merge to main but this is a tricky one to debug and I probably won't be able to figure it out for another day or so. Sorry about that!

[blakesmith]

@bunnie Ah, right, forgot about the stdlib update. After updating, I'm getting successful SystemTime::now calls! Woohoo!

Ok I got through an initial pass of comprehensive testing and fixed a few bugs, but I have discovered at a fairy late stage that suspend/resume got borked somehow, and also, there is something that is pegging the CPU but I can't quite figure out what (I think the two are linked -- seems like something is in a busy wait loop).

I wonder if it's what I was seeing: I don't have a way to accurately reproduce, but flashing a new kernel 20-30 times or so (and testing my app in between), attempts to sleep would freeze on whatever app was open, and then eventually trigger a reboot. This persists until I do a full factory reset (including PDDB reformat). No paper clip reboot helps. I kind of assumed I was doing something stupid in my app with PDDB access, and that state was carrying over, even between system reboots. Is this similar to what you're seeing? If not, I can keep poking to see if I can get more narrow steps to reproduce.

Either way, this initial SystemTime work is great! Thank you so much!

[blakesmith]

@bunnie Also, this sleep / suspend issue I'm seeing was happening before updating to your new time branch. I saw it start to happen closer to the "Block on PDDB booting" change (36ea69f), but I wonder if that might be a red herring. Not sure if you're seeing something similar.

[xobs]

There's a rather disheartening message about Instant and SystemTime from the SGX port: https://edp.fortanix.com/docs/concepts/rust-std/#codestdtimecode

std::time

Timekeeping in secure enclaves is an unsolved problem. The following functions use the current time as reported by the Operating System, which may or may not be the actual current time:

Instant::now
Instant::elapsed
SystemTime::now
SystemTime::elapsed

Security warning

Do not use the time obtained from these functions as the sole time source for making security decisions such as credential expiry.

[bunnie]

Yah, I think this is because SGX relies on the PC RTC for time which is not secured and not controlled by SGX.

We can control our time, so we don't have that problem. But we do have to set it.

[blakesmith]

After @bunnie's SystemTime libstd changes landed, I'm now able to compute TOTP codes against a static list of fake secrets, using the current system time! This is a software HmacSha1 computation, that also updates the code based on the SystemTime (you still have to force a redraw manually, to get updated codes).

I'll continue to test the SystemTime implementation as I go, but next steps for me are:

1. Integrate with the Hmac service, and the OpenTitan core to get hardware accelerated HmacSha256 and HmacSha512 hashes.
2. Have a ticker that redraws the screen every second or so.
3. Figure out a UI a main UI that looks good, and has a good UX.
4. Once I have the main "view my codes" UX fleshed out, figure out how how to load / delete / manage TOTP secrets, and go back to integrating with PDDB.

Super hacky / rough code is up: https://github.com/blakesmith/xous-core/blob/xtotp-time/apps/xtotp/src/main.rs. I'll continue to push and work off this branch as I go and share feedback / updates!

[bunnie]

I'm now at a point to start looking at integrating TOTP to mainline -- are there any updates or cautions I should be aware of? Is this still the correct branch to base off of?

[blakesmith]

@bunnie Sorry, I've been distracted with work and other commitments, so yes, that's still the current latest. Are you interested in having a TOTP application available in mainline, for users to use directly?

[bunnie]

Yes, we just got USB device working, and I'm poking at U2F implementations for the device. I think the "authentication hub" aspect of the device might be coming together a bit faster than the "secure comms" aspect, which is held up on getting TLS ported to the platform.

[bunnie]

Also, no worries about being distracted -- I'm more just poking my head in this direction to let the ideas soak a bit. Nothing is imminent, I'm still in the learning phase of what this is all about.

[bunnie]

Ok -- I have pushed time to the main and it seems reasonably solid under hosted mode and on real hardware (have not checked on renode (@xobs) but I don't think i did anything that would break renode).

If you find any bugs with time, can you please open a new issue, instead of placing it in this discussion thread? I think we're basically done with the architecture/implementation phase and now in testing, and I find issues to be an easier way to manage my workflow for tactical problems like bugs.

[bunnie]

I've absorbed your code into xous-core directly, hope that's OK:

xous-core/apps/vault/src/totp.rs

Lines 1 to 16 in 5d8b85c

	use crypto_common::InvalidLength;
	use sha1::Sha1;
	use hmac::{Hmac, Mac};
	use std::{
	convert::TryFrom,
	time::{SystemTime, SystemTimeError},
	};
	// Derived from https://github.com/blakesmith/xous-core/blob/xtotp-time/apps/xtotp/src/main.rs
	#[derive(Clone, Copy)]
	pub(crate) enum TotpAlgorithm {
	HmacSha1,
	HmacSha256,
	HmacSha512,
	}
	impl std::fmt::Debug for TotpAlgorithm {

It's now part of the vault app, which can manage various types of authentication methods, including FIDO, passwords, and now TOTP:

Just passed the first trivial test of things working, so this is looking good so far....

[blakesmith]

@bunnie Love it! Looks awesome. Thanks for carrying the work forward! I love that you integrated it into a broader password manager type application. Nice work!