End-to-end encryption

At Onboardbase, security is at the core of what we built and how we interact with third-party services. In this document, we will share the details about how we handle encryption to ensure enough transparency and help experts analyze our implementations and approaches.

Our Encryption Implementation

We use a combination of both AES-GCM and RSA to provide a secure hybrid security implementation - an implementation similar to SSL security mechanism.

Account/Login Sessions

Once an account has been authenticated, two RSA keys(public and private) are generated from the authenticating client, and upon successful confirmation of the authentication, the public key is shared with the server.

The private key is maintained on the client to further ensure confidentiality of any information the server would send to it afterward.

The generation of these public/private keys on each login session ensures that information shared with a client can only be read by that client alone, which secures the information against a MITM attack.

When the server receives a public key, it also generates its public/private RSA key authentication against the login session and sends the public key only to the client.

Both the client and server preserve their public/private keys but only share their public key with each other, which helps to enforce the integrity of encrypted information across the parties.

API Keys Passphrase

Service tokens are other means of authentication with Onboardbase. To enforce confidentiality, each service token is attached to a unique passphrase.

All data communicated via the API key authentication are encrypted, as shown via our public APIs. The end client must decrypt the data using the passphrase supplied when generating the API key to authenticate the request.

import * as CryptoJS from 'crypto-js'

function decrypt(encrypted_obb_data, passphrase) {
    const bytes = CryptoJS.AES.decrypt(encrypted_obb_data, passphrase);
    return bytes.toString(CryptoJS.enc.Utf8);
}

from aesdecrypt import decryptCipher

def decrypt(encrypted_obb_data, passphrase):
    return decryptCipher(encrypted_obb_data, passphrase)

require 'cryptojs-aes-decrypt'

def decrypt(encrypted_obb_data, passphrase)
     CryptojsAesDecrypt.run(encrypted_obb_data, passphrase)
end

import (
     aesdecrypt "github.com/Onboardbase/go-cryptojs-aes-decrypt/decrypt"
)

func decrypt(encrypted_obb_data, passphrase) {
     aesdecrypt.Run(encrypted_obb_data, passphrase)
}

You can learn more on decrypting secrets retrieved from the API in our dedicated API reference page.

Algorithms Used

We use both RSA and AES-GCM algorithms to enforce our security rules.

RSA

RSA is asymmetric encryption, and at Onboardbase, we use it when data has to be communicated between two ends(client and server), and the data is prone to pass through an untrusted middle man like the internet.

We use a 4096 key length as recommended by NIST (NIST, 2014), ENISA (ENISA, 2014), ANSSI (ANSSI, 2007), and BSI (BSI, 2018).

Onboardbase relies on standard libraries from programming languages to help in this implementation. For example, Golang Crypto Libraries, Ruby RSA Library, and Node RSA.

AES-GCM

For symmetric data(which does not need to be communicated back to the sender), Onboardbase uses an AES-GCM algorithm with a 16bit padded passphrase. This can be seen in the response of our GET secrets API.

Onboardbase relies on standard libraries from programming languages to help in this implementation. For example, Golang AES-Crypto Libraries, Ruby RSA Library, and Node CryptoJS.

Server Security

TLS

Communication to and from Onboardbase servers is secured via the SSL/TLS.

Secrets and other credentials can only be communicated to clients that have implemented the HTTPS layer. And in addition to the encryption mechanism, this security feature further prevents Onboardbase from being prone to MITM attacks.