[rank_math_breadcrumb]

SAS: Single Authentication String

by June 11, 2021 | Technology

Parsec is a system that provides its users with digital safes. Access to these safes can be shared with other users in the same Parsec organisation.

How to share and transmit the safe keys to a new Parsec user without compromising the system's security? How can we guarantee the identity of this user, and the confidentiality and integrity of the secrets in a digital safe?

Parsec, building an enrolment chain

In PARSEC, only the user terminal is considered a trusted zone. In addition to the concept of "Zero knowledge", where any information leaving the user terminal is unusable by a third party, PARSEC is also based on the concept of "Zero Trust". This paradigm implies the use of end-to-end encryption using keys known only to the user. These keys must therefore be certified and distributed between members of the same organization.

Part of the encryption key generation/distribution/certification process takes place during a ritual to enroll a new user (or a new terminal for an existing user) into the organization. The organization's administrator has the power to invite a new user and certify his or her identity (as the administrator has previously undergone an enrolment process, his or her identity is also guaranteed and certified). In this way, Parsec enrolment is no longer based on the "top-down" principle, but on the concept of distributing trust from one person to the next.

The enrolment phase in PARSEC is therefore a crucial stage, where cryptographic information will be exchanged. It is therefore necessary that this phase is protected from attacks (man in the middle type) by:

  • Guarantee of a secure transmission channel for transmitting and certifying the encryption keys to be used Guarantee and certification of the guest user's identity.

It is important to understand that this enrolment step is mainly used to transmit and/or certify encryption keys that will be stored locally (and encrypted locally) on the user terminal, or stored (for public keys) in the PARSEC metadata server.

Adding a new terminal to an existing user differs slightly from the mechanism for adding an invitation to a new user in that certain user keys are not generated but only passed from one terminal to another. The principle itself is however identical and can be seen as a single user enrolment.

The enrolment procedure

The procedure from a user's point of view

Let's get to the heart of the matter, the user/terminal enrolment procedure. From a user point of view the enrolment procedure is as follows:





Alice is an administrator of a PARSEC organisation and wants to invite Bob.

  • Alice fills in Bob's e-mail address via the Parsec interface.
  • Bob receives an e-mail containing the PARSEC installation procedure and a link that allows him to claim the invitation.
  • Alice and Bob start a conversation via a third party communication channel; in our example Alice calls Bob on the phone. This step is crucial to ensure Bob's identity and to enable secret communication via a communication channel independent of the PARSEC metadata server.
  • Bob uses the invitation link to start the invitation process.
  • Alice uses the Parsec interface to start the invitation process.
  • Once both procedures have been started, Bob communicates to Alice via the third party channel a 4-letter code which is displayed on her terminal.
  • Alice has to choose from 4 code proposals the one that Bob indicates to her
  • A 4-letter code is now displayed on Alice's interface, and she communicates it to Bob via the third-party channel.
  • Bob validates the 4-digit code among the 4 proposed.
  • The channel is now secure, so information and keys can be transmitted and signed in confidence.
  • Bob fills in his user information.
  • Alice validates the information.
  • Bob chooses a password to protect the secrets locally on his terminal (the keys and information about the organisation).

What is really going on?

Establishing a channel of trust

Alice and Bob do not communicate directly with each other but through the Parsec metadata server. Therefore, a trusted communication channel has to be established which must guarantee the secrecy of the communication and the authenticity of both endpoints (the guest terminal and the administrator terminal). This means that an adversary cannot interfere and perform a man-in-the-middle attack. It is also necessary to protect the metadata server and ensure that it does not receive any secrets.

The man-in-the-middle attack is an attack that aims to intercept communications between two parties, without either of them suspecting that the communication channel between them has been compromised.

Communicate with the backend:

In the first step, both parties (the guest and the administrator) connect, using the metadata server as a transmission channel, and start the invitation procedure. The guest is identified by the invitation link he/she has received by e-mail. The metadata server uses this invitation link to provide both parties with a unique token to identify the invitation process. The metadata server now prevents any further requests to use the invitation link because it is in use.

Alice and Bob must now determine a symmetric encryption key in order to encrypt and decrypt the sensitive data to be exchanged. This key cannot travel directly over the communication channel via the metadata server (man-in-the-middle attack). It is therefore necessary for Alice and Bob to exchange a minimum amount of information in order to derive the same encryption key without the data exchanged allowing a third party to calculate the key.

The Diffie Hellman algorithm:

Key derivation in Parsec consists of a Diffie-Hellman key exchange based on elliptic curves. The idea is to establish an asymmetric private/public key exchange protocol (based on elliptic curves and the X25519 algorithm) in order to obtain a shared secret (i.e. in this case a symmetric encryption key) through an unsecured communication channel (all exchanges on the communication channel must be considered as being visible by attackers).

Let's put aside the elliptic curves and focus on the basic idea of the Diffie Hellman. The algorithm is structured as follows:

  • Alice and Bob agree on shared numbers, known to all.
  • Alice chooses a very large random number which she keeps secret.
  • Bob chooses another large number which he keeps secret.
  • From the secret number and the known numbers, Alice calculates an intermediate number which is the result of a calculation. This number is then transmitted to Bob
  • Bob also calculates a number derived from his secret number and the common numbers and passes this result to Alice.
  • Alice combines, with a special algorithm, her secret number and the common numbers with the number that Bob has transmitted (already from a calculation involving Bob's secret).
  • Bob makes the same combination on his side.

The algorithm used must ensure that Alice and Bob arrive at the same result. This result cannot be guessed by an attacker because the factoring to find the secret numbers of Alice and Bob is too complicated to be solved by a machine.

In Parsec the Diffie-Hellman key exchange is based on elliptic curves, but the principle remains the same. Both parties use cryptographically compatible asymmetric keys on a common elliptic curve (Curve25519). They then exchange the public parts and keep the private parts. It is thus possible to derive a common symmetric key(more info )

Attacker's point of view

An attacker here only sees part of the information pass through, the complexity of the numbers and the complexity of the factoring makes it impossible for an attacker to recalculate the numbers that do not pass through the network and remain secret.

Short Authenticated Strings (SAS) :

What are the risks?

It is now necessary to ensure that the metadata server has not carried out a man-in-the-middle attack, a type of attack where the server would have intercepted the public keys and transmitted fake public encryption keys to each party, establishing two secret keys instead of one. In this type of scenario, the metadata server has the ability to decode the messages between Alice and Bob transparently.

The classical way to counter this attack is to sign the value exchanges using an asymmetric key pair certified by a trusted third party. In our case, we do not wish to use an intermediary, so there is no certification authority that can play this role.

How to protect yourself?

To protect against the metadata server, Alice and Bob need to ensure that they have the same encryption key, without communicating any information about the key. To do this, it is necessary to use a third party communication channel (in our case Alice and Bob call each other directly) to communicate information without it passing through the metadata server. This information must also be unusable if the third party channel is compromised.

To certify that the derived encryption key is identical on Alice's and Bob's terminals, both devices generate random nonces (random numbers used once). The idea is to verify that the transformation of Alice's number by her local key produces the same result as the transformation of Alice's number by Bob's key. Bob and Alice will therefore exchange their random numbers.

How does verification work?

Bob and Alice exchange their respective random numbers via the communication channel through the metadata server. Bob will use his secret key to combine Alice's number with his own (keyed hash).

If the two keys are indeed identical, the operation should give the same result for Alice and for Bob. The result of this operation is a 40-bit number.

The last 20 bits of the generated number will be used as authentication tokens. The PARSEC interface will represent this number as a 4-letter code and display it on Bob's interface. The same operation will be performed on Alice's terminal using the number she has calculated. This time, the interface will generate 3 other random 4-letter codes.

At this stage, it is necessary to use the third party communication channel to validate that the two numbers obtained are identical. The attacker cannot intercept the exchanges on this communication channel. Moreover, the information exchanged on this channel does not contain any element allowing the reconstruction of the common encryption key between Alice and Bob.

Bob will therefore communicate via the out-of-band channel (by telephone in our case) the 4-letter token. If the encryption key is the same for Alice and Bob, Alice must have this number available among the 4 options. If the number is not available, the key is different and the channel is compromised, no exchange can be established.

The same operation is performed in the other direction, but this time with the first 20 bits of the number calculated on each terminal. This time, it is Alice who communicates her 4-digit code and Bob who validates it among 4 propositions on the PARSEC interface.

Now we can guarantee that the communication channel is secure between Alice and Bob because they are both the sole owners of a symmetric key that will allow messages to be encrypted and decrypted. Thus, confidential information related to the enrolment of a user can be exchanged.

How can we be sure that the attacker has not intercepted the random numbers?

In the case of a man-in-the-middle attack, the attacker can intercept the random numbers generated by Bob and Alice and generate new ones. It is therefore necessary to guarantee that the number Alice receives is indeed Bob's. Before the steps described above, it must therefore be guaranteed that the numbers exchanged between Alice and Bob have not been falsified.

To do this, Bob first calculates a hash of his random number (before transmitting it). A hash function is a transformation of the number that allows the calculation of a digital fingerprint used to quickly identify the initial data (here Bob calculates the HMAC-SHA256).

Bob only transmits the hash of his random number to Alice. Alice acknowledges the hash of Bob's number. Alice transmits its number to Bob. Bob then transmits the random number he generated.

As described above, the hash of the number is a kind of fingerprint of the number. It is easy to calculate the fingerprint from the number but impossible to calculate the number from the fingerprint.

Alice will perform the same hash operation on Bob's number and compare it to the hash that Bob sent her earlier. If the number has not been modified, Alice obtains the same result as Bob. The security here is based on the fact that it is impossible for an attacker to recalculate Bob's number from the hash he receives. Thus the attacker cannot falsify Bob's number because Alice verifies that the hash of the number transmitted by Bob is identical to the hash she calculates from the number sent by Bob. Bob and Alice are now sure that they have the same number in common

Attacker's point of view

At this stage of enrolment, an attacker using a `man in the middle' attack would have passed false information to Bob and Alice. The encryption keys are therefore different on each workstation. Now, the attacker must succeed in falsifying the secret code exchange. However, it is almost impossible for the attacker to forge the numbers A and B (1 chance in 1000 billion) because the sending of the numbers is done in several steps. Let's take the point of view of the attacker. The attacker knows Alice's key (sk_alice), he cannot modify the number A which was generated by Alice. He must intercept Bob's number B and provide Alice with a fake number B_fake. The attacker knows Bob's key (sk_bob), he cannot modify the number B that was generated by Bob. He must intercept Alice's number A and provide Alice with an A_fake number. The attacker must therefore calculate the numbers A_fake and B_fake such that:

sk_alice(A + B_fake) = sk_bob(A_fake + B)

However, the numbers are not transmitted directly. The attacker first receives the number B hasher, without knowing either A or B. The attacker must therefore calculate B_fake without knowing either A or B because he must transmit the hash of B_fake to Alice. The attacker is then blocked because he must then transmit A_fake from A, without knowing B, while he has already transmitted information about B_fake to Alice. There is therefore very little chance that the attacker will be able to calculate the numbers A_fake and B_fake which validate the previous equation. The attacker's only chance is to try to find the number B when transmitting his hash, but he will run into hash collisions to compute B (a pair of distinct data from his starting set whose checksums are identical).

Data exchange during enrolment

Cryptographic keys in Parsec

Let's take a look at the cryptographic mechanisms of Parsec.

A user has several encrypted keys (which allow secure exchanges and access to information) and signature keys (which guarantee the integrity of data and exchanges).

The User Encryption Key

A Parsec user has an asymmetric encryption key that is used to receive encrypted messages. An asymmetric key consists of two keys, a public key that is used to encrypt information, and a private key that is used to decrypt the information encrypted by the public key. The public part of the key is transmitted to the Parsec metadata server and is used when a message is to be sent to the user. The private part of the key is carefully stored on each user terminal, thus ensuring that only the user of the terminal can read the messages sent to it.

Terminal signature key

Each terminal has a signing key. Like the encryption key, which is specific to the user, the signing key is attached to a terminal. This key is used, among other things, to sign modifications that are sent to the metadata server (this mechanism guarantees the integrity of the data). As with the user encryption key, this signing key is asymmetric and consists of two parts:

  • A private part which remains on the client terminal and which allows to sign the modifications
  • A public part which is sent to the metadata server and which allows other users to verify the signature.

Symmetric user metadata key

The user's metadata, stored in the metadata server, must be accessible only by the user. This metadata serves as an entry point into the system by listing the available shared spaces and the information to access them (identifier and key to decrypt the metadata of a workspace). This user metadata is stored on the metadata server. It is encrypted and decrypted by a symmetric key present on each user's terminal.

Local encryption key

All data downloaded and decrypted by Parsec on the client computer is re-encrypted locally on the terminal by a local encryption key used only on the workstation. This key ensures that the data cannot be accessed if the user is not identified in Parsec.

In summary

A user has local ownership of all these terminals:

  • The private user key for receiving messages, (the public part is available on the metadata server).
  • A symmetric encryption key to decrypt the metadata of the Parsec server linked to his user account.

It also has locally on each terminal (unique to each station)

  • A terminal key to sign the changes.
  • A local encryption key to access the data already on the terminal.

These four keys are stored in a configuration file on the terminal. This file is itself encrypted by a key derived from the user password (Challenge/Response encryption).

The user invitation mechanism

Once the trust channel has been established between the two terminals (a process explained in the previous section), Bob will be able to retrieve sensitive information and generate and transmit these encryption keys. Alice will certify Bob's identity by signing these public keys.

Bob's Parsec client starts by generating an asymmetric user encryption key and an asymmetric terminal signature key.

Bob encrypts these two public keys with the common secret symmetric key between Alice and Bob established during the creation of a trusted channel. Only Alice and Bob have knowledge of this key.

Bob then sends his two encrypted public keys to Alice via the metadata server. Alice can then decrypt the message sent by Bob with the secret key.

Alice signs Bob's public keys that she has just received with her own terminal signing key. She thus guarantees the identity and integrity of Bob's public keys. It is therefore possible for a user who wishes to send a message to Bob to verify that the public encryption key is not compromised, by looking at the signature performed by Alice. The integrity of Alice's signing key can itself be verified by the user, as this key was also signed when Alice was enrolled. It is therefore possible to certify the entire chain of trust by verifying the signatures until they reach the first user in the organisation. Parsec thus provides a chain of trust.

Alice will send Bob a message (encrypted by the secret key of the communication channel) that contains the root key of the organisation. This root key is the first signing key used to certify the key of the first Parsec user. This allows Bob to verify the signature chain.

Finally, Alice sends the new user Bob's certified public keys to the metadata server, which sends confirmation to Bob's Parsec client that he is registered.

Bob, on the other hand, has also generated the encryption key for his user manifest and the encryption key for the locally stored data. Bob encrypts his user manifest and sends it to the metadata server.

All information that should not be transmitted outside the Parsec terminal is stored in a local file. Bob enters his password on the Parsec interface, and this is used to derive an encryption key that is used to protect and encrypt this local file.

By PARSEC

In the same category

Optimize Rust build & test for CI

Optimize Rust build & test for CI

Last year, we migrated our CI to GitHub Actions after previously using Azure Pipelines. We took advantage of the migration to improve our CI. This article will summarize the different steps we have taken to enhance our CI when working with Rust. Parallelize Run...