Is a Solid client on an Arduino Uno achievable?

[kjetilk]

I can't get myself into much more in the project, but it seems like this question has quite a lot of interesting implications, so it might be a topic that the panel should discuss.

So, first Arduino Uno is a cheap and small microcontroller. It has 2 kB RAM, 1 kB EEPROM and 32 kB of Flash. And yet, it can do quite a lot. I have Web servers on a couple, so that I can pull data from it.

It would be interesting to take it a step further, to have a Solid client on it that be authorized to write to parts of my pod, in which case, it would be push, not just pull. With the constraints it has, it will be pretty hard, but therefore also interesting.

One issue is how to identify it and authorize it. I think that we could perhaps just add something to Solid that could mint a URI for it, so, you wouldn't have a full WebID for it, merely a URI that can be used in ACLs. It could be accompanied by a shared secret, a token that could be flashed into the EEPROM.

It seems difficult to implement TLS over it though. So, could we possibly do something of lighter weight? Just pass JWT across the network with symmetric crypto based on a shared secret between the Arduino and the Solid server? The Solid server would then have a trigger that would decrypt the message and possibly perform some semantic lifting before a representation is created?

[dmitrizagidulin]

+1, this is a great topic. And as you can imagine, everybody who wants to do something with constrained IoTs bumps up against this. I'm sure we'll discuss this in more detail, but I want to add two quick links:

• On the practical side: the ongoing work over at the Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework working group.
• On the academic side: A Survey of IoT Authentication Schemes paper.

[jaxoncreed]

Agreed interesting topic. It might be solved with something as simple as a client-credentials grant where you would share your credential secrets with the IoT device and it could automatically authenticate.

Though, if you don't want to share your credentials with it, then it becomes a bit more complicated. It could possibly send a notification to your Pod that would open a window on your personal device to allow it to authenticate.

[kjetilk]

Agreed interesting topic. It might be solved with something as simple as a client-credentials grant where you would share your credential secrets with the IoT device and it could automatically authenticate.

Yeah, but the thing is that I want to give it a URI too, and use that URI to set acl:Authorizations for it.

Though, if you don't want to share your credentials with it, then it becomes a bit more complicated. It could possibly send a notification to your Pod that would open a window on your personal device to allow it to authenticate.

Yeah, but what I had mind was actually that you didn't give it your credentials, but you could, under your own pod, give devices URIs, and then generate credentials to authenticate that URI... Something like that.

[jaxoncreed]

you could, under your own pod, give devices URIs, and then generate credentials to authenticate that URI

Could you go into more detail on the step-by-step for that?

[kjetilk]

Perhaps, it is a very loose thought, so more a braindump than a step-by-step, but here we go:

1. An app that is authenticated as a normal user creates a resource, e.g.

https://iot.example/devices/thermo.ttl

which has some Turtle

<#thing>  a sso:SensorDevice ;
  ex:hasToken <https://iot.example/devices/private.ttl#thermo> .

The latter is a reference to a resource that must be adequately protected, since it contains a secret:

<https://iot.example/devices/private.ttl#thermo> ex:bearerToken "sdgjdsolfgjsoiljfgsdg" .

Just got some inspiration from UNIX' /etc/passwd and /etc/shadow :-) . The owner may then grab the bearer token and set it in the EEPROM of the Arduino for a client to use when authenticating to a Pod.

The URI of the device would be given in the token https://iot.example/devices/private.ttl#thermo, and when dereferenced it will show where the bearer token resides...

But now, I start to realize that the idea kinda falls apart (that's what sometimes happen when you try explain a loose idea), because the server would have to have access to the private file but it can't through the Solid interface, because you can't just have any server access that. It could work if the private file is on the same RS as the resource the device wants to access. But that's just a small subset of what I wanted to achieve here, even though it covers 100% of my current use cases for it...

If we could live with that, then the server would just verify the bearer token against the token on file.

So, it seemed somewhat attractive to have just a shared secret at first, since that could be pretty small, and all you'd need on the Arduino is a string in EEPROM and it wouldn't need to compute anything. But perhaps if it is a public key that sits on the server side, that doesn't need to be protected, and that the Arduino has the private key in the EEPROM?

Now, I should probably not be trying to design these protocols to begin with, but rather leave that to the folks @dmitrizagidulin is referencing. :-) But now that it is written, I figured I might just leave it here, just in case there is some idea that could be useful.

[zenomt]

just thinking out loud here...

if your IoT device could do https, how about something like (for the IoT profile):

@base <https://iot.example/bot.ttl> .

@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
@prefix prov:  <https://www.w3.org/ns/prov#> .
@prefix basic: <TBD> .

<>
	a foaf:PersonalProfileDocument;
	foaf:primaryTopic <#me> .

<#me>
	a foaf:Agent, prov:SoftwareAgent;
	foaf:name "Cool IoT Bot";

	basic:password [
		a basic:PasswordHash;
		basic:audience  "https://server.example/bots/"; # any URI with this prefix
		basic:algorithm basic:sha512;
		basic:hash      "D716A4188569B68AB1B6DFAC178E570114CDF0EA3A1CC0E31486C3E41241BC6A76424E8C37AB26F096FC85EF9886C8CB634187F4FDDFF645FB099F1FF54C6B8C"^^xsd:hexBinary
		# sha512("abcdefg") ^^^
	] .

	# client would send
	#   Authorization: Basic aHR0cHMlM0EvL2lvdC5leGFtcGxlL2JvdC50dGwlMjNtZTphYmNkZWZn
	# (base64("https%3A//iot.example/bot.ttl%23me:abcdefg"))
	# for any URI starting with "https://server.example/bots/".

the password is audience restricted so that, since the plain password is divulged to the audience, it can't turn around and use that password anywhere else.

the IoT device would just need to be configured with its webid and password(s) for its audience(s), assuming its profile is stored somewhere else. this scheme isn't constrained to IoT devices of course.

obviously since the hashed password is in the public profile, a real password used in such a scheme would need to be longer so that brute forcing wasn't feasible.

[zenomt]

servers would need to support this Basic scheme too:

WWW-Authenticate: Bearer realm="/auth/", scope="openid webid",
    Basic realm="/auth/", scope="webid"

[zenomt]

or, to get the benefits of server-issued access tokens (see #12), my auth proposal could be extended with a "get an access token with basic auth" method, that would otherwise work just like the WebID-TLS token endpoint:

WWW-Authenticate: Bearer realm="/auth/",
    scope="openid webid",
    nonce="j16C4SOLQWFor3VYUtZWnrUr5AG5uwDF7q9RFsDk",
    webid_pop_endpoint="/auth/webid-pop",
    webid_tls_endpoint="https://webid-tls.example.com/auth/webid-tls",
    webid_basic_endpoint="/auth/webid-basic"

[kjetilk]

@zenomt

if your IoT device could do https, how about something like (for the IoT profile):

I don't think TLS can be assumed. I haven't seen any successful implementations. The Arduino Uno has just 2k of RAM, so you can't even fit a 2048 bit key in there (assuming there are other things than the key)... However, perhaps it is the assumption that you need to have deal with public keys that has made it hard? Could perhaps TLS-PSK make it workable? I really have no idea. I think it is attractive to not need a password too, if a shared key could do.

But yeah, the profile should be stored elsewhere (that's why I'm thinking simply the owner's pod).

[elf-pavlik]

I wonder if this conversation wouldn't fit better on https://forum.solidproject.org/
Otherwise we should add some clear acceptance criteria for resolving this issue.

[acoburn]

This issue is out of scope for the Solid-OIDC panel. If there are particular portions of the specification that make it incompatible with constrained devices, such as an Arduino, a new issue should be created, focused on that particular area.