Skip to main content

2 Web of Trust

We define Web of Trust as a Set of shared VaultysId. Each VaultysId owner has his own set of VaultysId to communicate with. The keys contained in the VaultysId can be used to sign or encrypt data. Each service can use its own protocol deriving keys from them.

However a protocol is defined for the trust setup, ie in order to integrate the set of reliable keys. The protocol is called Symetric Relationship Protocol (SRP) as it aims to create a certificate signed by both parties and ends-up to be the same on both side.

2.1 Symetric Relationship Protocol​

Between Bob and Alice each having a VaultysId. Data being exchanged are:

  • protocol name (for instance p2p)
  • service name (for instance auth)
  • timestamp, used to prevent from replay attack
  • id1 and id2 are VaultysId of Bob and Alice Respectively.
  • Nonce (random)
  • sign1 and sign2 are signatures created by the signing key of Id1 and Id2
  • metadata1 and metadata2 are JSON objects that can be empty We can sumup the protocole using the schema: message = { protocole, service, timestamp, id1, id2, nonce1, nonce2, metadata1, metadata2 } sign1 and sign2 are signatures using signing keys of id1 and id2 of sha256(messagepack(message))

Metadata is user defined by protocol and service. For instance we can use metadata to exchange name, email and phone between parties so they are certified inside each other Web of Trust.

We define:

  • M1 = protocol, service, timestamp, id1, nonce1, metadata1
  • M2 = id2, nonce2, metadata2
  • sign1 and sign2 are signatures of sha256(M1 | M2)
  • certificate = sha256(M1 | M2) | sign1 | sign2
  • certificateId = sha256(certificate)
  • Messages are serialized using MessagePack

The Protocol needs to rely on the following infrastructure

  • A bidirectionnal communication channel already known to Bob and Alice. Active attack is allowed except for initial handcheck (see later)
  • A storage able to save Id and certificate. The security model for storage is passive attack (ie be able to read the data, not tamper with).

2.2 General description​

  • Bob -> Alice : send M1
  • Alice verify this is the intent in protocol, service, metadata1 she wants to use and data is coherent.
  • Alice verify that timestamp is within reasonable time (define by the protocol)
  • Alice -> Bob: send M1 + M2 + sign2
  • Bob verify metadata2, sign2 are coherent
  • Bob -> Alice: sign1
  • Alice verify that sign1 is valid
  • Alice -> Bob: COMPLETE in order to ack the end of communication
  • Alice and Bob save the Ids together with the certificate which is the same for Alice and Bob
info

 In a future version of the protocol, COMPLETE might be replaced by the certificateId when it will be defined.

2.3 Initial Handchek​

The initial Handcheck is a way to exchange unknown keys between parties. The active attack where a attacker can change data during the protocol is out of the scope of the security model. The mandatory setup for security:

  • face to face protocol realisation.
  • secure p2p channel:
    • with a temporary random key exchanged (via QRCode for instance) that is used to encrypt the data exchanged in the protocol
    • No forward secrecy is needed
    • The key is destroyed afterwards. The protocol is resistant to later recovery or passive attack. The constant are defined:
  • protocol = p2p
  • service = auth
  • timestamp deviation is 10s
  • metadata1 and metadata2 are empty.
info

In case of not face to face handcheck timestamp can be relaxed to a few hours (typically 2 hours), but it is reminded the security model assert that the communication channel to transmit information or endpoint (email, chat, SMS) is NOT compromised during the handcheck.

2.4 Authentication​

Once HandCheck protocole has been completed, it is possible anytime after, to authenticate each other. For instance we replace classic login system based on username/password/mfa by this single authentication scheme:

  • protocol = p2p
  • service = auth
  • timestamp deviation is 10s
  • metadata1 and metadata2 are empty.

The verification on both parties Alice and Bob have an extra step, checking the validity of the handcheck registration certificate on both sides:

2.5 Reference implementation​

2.6 Example​

Channel implementations​

Channels are abstract object to exchange data in bidirectionnal way. In essence 2 methods are needed:

  • send(data): void to send data in fire and forget
  • async receive(): data to wait for data reception

We provide 2 implementations:

  • P2P channel using webrtc (via the library peer.js)
  • Server/Browser channel relying on
    • native fetch() for the browser
    • expressjs or nextjs middleware for the server.

There is for testing a Channel Mock (using RAM in the same process) We are working on several other implementation like Patr