Provide secure storage and private keys

[barbieri]

Task Description

Secure storage of keys is essential in real-world products, we do not want private keys to be accessible and it is common requirement to have secure storage for important bits.

A way to do it is to use Linux's Trusted Platform Module (TPM) which will use hardware whenever available. Another is to use Intel's gSSO (https://01.org/gsso) which abstracts that and bit more.

We should investigate which approach to use. gSSO looks easier to use, but brings more dependencies. We may check with @ereshetova and @jlaako which know them very well to see how to proceed.

What we should keep in mind for Soletta:

• how to make it work with posix main loop
• how to make it work on micro-linux, that is, single process, without a daemon. Maybe would need different implementation (ie: sol-...-impl-gsso.c)?
• should we expose this as a different C API (ie: sol-sso.h or sol-securestorage.h...)?
• should we expose this as a set of different node types? Or have existing node types to support them, like oauth and persistence.

Relevant contacts:

• @ceolin (did oauth)
• @edersondisouza (did persistence)
• @jlaako (gSSO)
• @ereshetova (gSSO)

[ereshetova]

Please take into account that we are not only talking about storing private keys, but there maybe other credential types that needs to be stored, so the solution should be flexible enough to take that into account.

Also, a good SSO solution is not just a credential storage (this is easy to make), but should provide mechanisms to perform operations on credentials it securely stores without revealing the credential itself to an application. It should support a way to define what operation on what credential a certain app can do. In that case, if a certain app is found out to be malicious, its access to operations on credential can be revoke without the credential itself being compromised (and therefore re-provisioned). This a requirement that greatly enhances security.

[barbieri]

Great addition @ereshetova.

My only doubt is about the micro-linux case. Ideally in this mode we have a single process userspace (a /init that is the app, this is made easy with Soletta). In this case we try to provide the same API and a feature subset that is useful. Then what to do with gSSO in that case?

We can have multiple implementations, so we could require the TPM in the kernel and use parts of that interface to provide the minimum feature subset.

From the IoT products I've investigated, the most common operations are secure storage of small tokens (ie: some services that do not use modern authentication and requires user to type actual user/pass), verifying signatures (ie: to verify update is correct), HMAC and signing (basically oauth and OIC). Then yes, it matches what you say about not only storing the credentials (first case), but also doing the OAuth or OIC pairing processes without retrieving the keys to the application.

[ereshetova]

I think when it comes to size, let's ask @jlaako if he has ideas on how to scale down gSSO for that case.

[barbieri]

ok, figures so you know: Soletta with FBP and OIC is around 400kb total, statically linked with musl-libc and stripped. A BLE heart-monitor using FBP is around the same size. That is the userspace size, single binary (/init).

Ideally we shouldn't increase much that size if all we need to do is oauth or secure storage of some key.

[jlaako]

gSSO depends, as the name says, on glib, gobject and gio (gdbus) that's where most of the footprint comes from. For some of the plugins also libgcrypt+libsoup(gnutls) are needed...

[barbieri]

how cumbersome would be to change gobject/gio/libsoup to libsystemd? It provides easy to use sd-bus.h and is already required for systemd itself.

Glib is already required for other daemons, most of our comms. But none of them require gobject/gio/libsoup.

I'd not say this is a blocker, but something to consider for the future.

[jlaako]

Just almost complete rewrite, so at least a man year effort. Entire framework is object oriented built around GObject.

I've been implementing this framework already twice, once for Qt and second time for glib. Not really keen doing third reimplementation.

libsystemd is anyway controversial and Linux-specific. gSSO is not Linux-specific but works also FreeBSD, etc.

Does libsystemd also prove a HTTP stack with proper proxy traversal and TLS/SSL support? This is necessary for OAuth.

gSSO design doesn't make sense for single-process systems lacking process isolation anyway because then you by definition don't have protection.

[barbieri]

I agree that implementing it yet-another time will be painful. As I said, Glib itself is not an issue since connman, ofono, bluez all needs it. But they only need the basic Glib. Actually these use a Glib-DBus layer that is much, much easier to work with than GDBus, worth checking with @holtmann or see the code.

As for http stack, AFAIU they don't, people rather use libcurl. Which we need in Ostro due swupd and soletta anyway.

[jlaako]

One reason we use GDBus is that it nicely supports P2P D-Bus which is essential requirement for gSSO. We prefer not to go through dbus-daemon for security reasons, instead applications talk straight to gsignond using the client library (D-Bus protocol). Another reason is nice integration for GLib's complex data structures over D-Bus since we have lot of things like nested variant maps - "a{sv}" inside "a{sv}" inside "a{sv}". We also need proper support for D-Bus over pipes and such because we do things like fork()/exec() where child inherits pipe descriptors and then hooks D-Bus on those (not socket - pipe pair)!

Which brings me to another topic that would double the reimplementation effort. So far we got the libgsignon-glib client library fork from the original (Qt-based) SSO project and we are still C API/ABI compatible with the original (which is why for example Elementary OS is using gSSO). Moving away from GDBus and GObject would mean rewriting also the client library.

Overall, gSSO footprint is small when running and we anyway already have gobject and gio installed on Ostro images.

If you want something small for single-process systems, gSSO is anyway wrong choice and you should go with something else an use hardware based security implementation like TPM straight.

Canonical is maintaining the original SSO implementation and we are maintaining the gSSO. Maintaining yet another implementation would also increase the effort considerably. So certainly I don't want to even think about such.

If someone else wants to take and reimplement the entire thing, I'm fine with that, but I want to stay away from such.

[barbieri]

Well, P2P D-Bus is basically just a matter of opening the right path. AFAIU all libraries can do that.

The complex data structure is also used a lot, mostly all standard ObjectManager or Properties interfaces uses them, then they are well supported in all libraries I've seen.

For the client library, at least in Soletta we'll have to do it ourselves as we use sol-bus.h and internally it is sd_bus.h. So doesn't matter much to us.

To wrap up the summary, Soletta should:

• use gSSO server as is
• offer a SSO "-impl" that talks via DBus using sol-bus.h
• offer an "-impl" that talks to TPM in micro-linux case (low priority)

@ereshetova is checking if kernel's crypto API could use a digest key right from TPM. If this is possible, then by using our sol_message_digest and kernel crypto we could at least do oauth with our current code without exposing the key to userspace. Then it would work nice on micro-linux.