chat can impersonate any webId

[bourgeoa]

This is a real problem. See the discussion in https://gitter.im/solid/solidos?at=63c8360a3031eb336184db17

Some ideas appeared in the discussion :

• save the chat messages on the message creator pod
• list authorized origin in ACL
• used of messages signatures
• I would add a new one around the idea of registering allowed users in Allowed Groups.

[bourgeoa]

Some details on the registering of allowed users :

Registering can be an chat extension to the address book aka contact-pane

At registering time a chat user folder can be created for each user with :

• acl Read/Write to the registered user (may be also the chat owner for management purpose)
• acl Read to every one (or limited to the Allowed Groups)
• message id will be stored in the chat user folder

With this :

• you can still impersonate a user in the chat.ttl document.
• but the app will not recognize the impersonated message as a valid one because not in the chat user folder
• and the chat will not display the impersonated message

[bourgeoa]

message id will be stored in the chat user folder

We may have only a private key stored in a chat user document
This private key can encode the message relative url or the message created date and give a unique security key to store with the message. To improve security message content could be added.

The pod chat owner should be able to rebuild a security key whenever a replacement private key is created
That is an audit issue

[timbl]

Another way of doing this is to use the server-side shape validation. To specify a shape which insists not only that a given shape s senr, but also that the USER and the DATETIME are used as fields in the shape.

[NoelDeMartin]

Adding to what @bourgeoa said, maybe we could define a more generic solution for encrypting data in Solid, not just for chats.

For example, we could have triples such as this in the profile:

<#me>
    solid:privateKey <./key.pem> ;
    solid:publicKey <./key.pub> .

Where ./key.pub is public (read-only, of course), but ./key.pem is private and only the POD owner can read it.

Using these keys, we could add "proofs" to other triples/resources. For example, in a chat:

:Msg123456
    dct:created "2023-02-05T16:25:49Z"^^xsd:dateTime;
    sioc:content "this is a message";
    foaf:maker c1:me;
    solid:proof "...".

Such that the value of the solid:proof is an encrypted message of the other triples (normalized, etc). In that way, only the actual user (foaf:maker in this case) can write the proofs, but anyone can check that it's been written by them.

Also, something nice about this is that it can be a client-client standard, so server implementations don't have to change for this to be supported.

[bourgeoa]

@NoelDeMartin thanks.
Question : why not use private/public index to store the keys the triples ?

The proof functions could be in solid-logic.

[NoelDeMartin]

@bourgeoa I guess they could be in the type indexes, but that requires using two specs (the type index spec, and the new "security" spec). So I think it's easier just to have it directly on the profile (or extended profile). But sure, I don't see any problem with having them elsewhere if there is any good reason.

About where to have to functions to generate proofs, yes we could have them in solid-logic but it's also important that the spec indicates how the proofs are generated, so that anyone can implement their own algorithm.

[bourgeoa]

@NoelDeMartin Does the security spec covers the client-client ? I thought it was covering client-server.

how the proofs are generated

Are you speaking of the content uses to create the proof. For the chat case which should be Append only the use of the message absolute URI as proof should be enough. Well relative to chat URI might be enough and retain possibility to move the chat to a new pod location.

I have discovered the nostr-tools. n04 https://github.com/nbd-wtf/nostr-tools#encrypting-and-decrypting-direct-messages could cover our needs.

[NoelDeMartin]

Does the security spec covers the client-client ? I thought it was covering client-server.

Well, my proposal is to make it client-client because that way we don't have to wait for servers to implement anything. But sure, it'd be a lot better to make it in the server.

Are you speaking of the content uses to create the proof. For the chat case which should be Append only the use of the message absolute URI as proof should be enough. Well relative to chat URI might be enough and retain possibility to move the chat to a new pod location.

Yeah I suppose if the chat is append-only, the URI would be enough but I don't think we should rely on this. Also because append-only means users can't delete messages, which is an issue. On the flip side, if it's not append-only it means anyone can delete other people's messages :(. But I can't think of a way to work around that without modifying the server spec.

[NoelDeMartin]

@timbl Suggested that a good compromise would be to keep it append-only for most people, but moderators would be able to delete messages.

Building on top of that idea, we could allow people to edit or delete messages, but it would initially be a "soft edit" or "soft delete" (meaning that the document would contain the history of messages, but the UI wouldn't show it). Then, moderators could "approve" those actions and make them effective by really editing/deleting the comments and removing the soft operations.

[timbl]

Yes, that would be a good compromise to only allow moderators or admis ti delete messages. For everyone else it is an append-only world.

[timbl]

One model is that the chat for the day is a folder like ...solidos/solidos/2023/01/01 which is appendable by group members adn writeable by admins. You send a message by writing a new file for that message like

...solidos/solidos/2023/01/01/123406K8jfygTt.ttl

You can make it with a post or a PATCH. Then in the listing of the folder, we save the creator of the file and expose it in the metadata. This is an existing idea which there should be an issue for somewhere. It needs a server change

[bourgeoa]

Ontologies to use for the credentials verification and proof.
Looking in verifiable credentials https://w3c.github.io/vc-data-model/#base-context I found the followings ontologies :

• https://w3c.github.io/vc-data-integrity/vocab/security/vocabulary.html#proofValue
• https://w3id.org/security#proof.

The predicate https://w3id.org/security#proof will be be used for the signature.

To describe the signature process this can be done using the verifiable credentials examples. The key being permanent for each webID there is no need to store it in the message. The process can be described only once in the chat index.ttl.
An issue arise when a user/webID decides to change his key pair. A solution could be to register the user. The key would be delivered by the registering process and replace the webId as message Owner.

[bourgeoa]

There are RSA et more recently ECDSA certificate types (letsencrypt is is using ECDSA as from version 2 by default.
ECDSA is more efficient quicker and have much shorter keys at the same level of security.

nostr-tools offers wrapper functions to create and use ECDSA certificates.
the nostr protocol N19 also offer a identity based on the key

[bourgeoa]

@SharonStrats
I came to this general idea :

• use asymetric keys private/public keys
• the key pair is attached to the webId but there may be more than one (?) :
  • the public key READ for everybody and can be located in the profile/card
  • the private key READ for webId only, can be discovered through privateIndex
• for security reason it would be nice to be able to :
  • rebuild the public key (this is possible using the eliptic curve)
  • encrypt the private key with a password (to be discussed because it adds a burden to the user, I would prefer a way to decrypt the private key at login)
• use the private key to sign a message with a proof being the encrypted hash of messageId+messageContent+owner
• check the proof by decrypting the proof with the public key and comparing the hash of messageId+messageContent+owner

As an inspiration for this process we can use :

• the implementation of eliptic curve keys made by nostr-tools https://github.com/nbd-wtf/nostr-tools/blob/master/event.ts and https://github.com/nbd-wtf/nostr-tools/blob/master/keys.ts
  the keys are rather short and public key can be recreated directly from the private key
• pod-chat-client https://github.com/0l5en/pod-chat-client/blob/main/src/store/solid/Crypto.ts
  the implementation is near what we need except that the keys are RSA and that that the key pair is attched to a webID and a folder app. SolidOS chat are multiples and the key pair must be attached to a webID or a webID plus an app type (LongChat for example)

[SharonStrats]

I'm wondering what initiates the key pair generation and our transition plan.
Thoughts? @bourgeoa @timbl @NoelDeMartin
Also just to confirm so this is client-client?

Ideas

Key Generation

• When a user creates a new long chat, we check for keys if not present they are prompted to create keys (button that says "Go to Key Generation"). This takes them to a key generation screen. There we also have a button "Key Generation" that when pressed creates the keys and stores them as specified above in bourgeoa's comment.
• When a user adds a message to an existing chat it checks for keys and if none exist it also prompts them to create their keys.
  Note: no chats or messages can be created from the point this is deployed without keys.

Transition plan

• Previous chats will not have signed messages. When displaying we will need to check if messages are signed. If they are not we could ask the user would you like to sign your messages in this chat. If so we do the above, check if they have keys and if not direct them to create their keys. Only their messages would be signed of course. All users chatting would need to go through this process to sign their messages. There will be chats with some signed messages and some unsigned.

[bourgeoa]

Also just to confirm so this is client-client?

At this stage yes. There is no server side specification

Key Generation

It is an app process and should be fully automatic.
Later if it is felt that the private key is at risk we may add a second level of security with a password. But it is not the spirit of Solid. WAC should do the job. At least for a chat

Note: no chats or messages can be created from the point this is deployed without keys.

I think that's correct.

Transition plan

I was thinking to have a date parameter or better to display in red or any other colour messages without a proof. This is different from messages where the proof fails.

[Otto-AA]

use the private key to sign a message with a proof being the encrypted hash of messageId+messageContent+owner

A small remark on this: I'd suggest to sign all message fields. In particular also the timestamp and recipient. There's some more discussion here on what could go wrong, feel free to poke me for questions on this: https://forum.solidproject.org/t/update-pod-chat-messenger-2-0-solid-pod-messaging-app/6141/13

[bourgeoa]

A small remark on this: I'd suggest to sign all message fields. In particular also the timestamp and recipient

Agreed I forgot the timestamp. When I wrote messageID I was thinking of the messageUri, that will include what you called the recipient.