• Security

  • The security of Egendata is, of course, of paramount importance. A lot of work has been put into finding a good combination of secure encryption implementations while keeping it simple for users as well as services who want to integrate against it. It also needs to be able to run on a variety of systems, both service platforms and mobile devices.

    Standard encryption frameworks

    We use modern encryption frameworks that already exist on all major server platforms, cell phones and even browsers.

    Signed communication

    All communication between the different parts of the platform are signed using JWS (JSON Web Signing) using RS256 or PS256 with 2048 bit keys unique to each party. This ensures that, even if a domain expires and a nefarious party takes control, they cannot gain access to the information awarded the former owner. Also MITM attacks using, for example, weak DH implementations are avoided.

    Encrypted data

    Your data is encrypted using JWE (JSON Web Encryption). This can be done with a multitude of algorithms but the one we chose is AES128CBC-HS256 (this might soon change to AES256CBC-HS512) with recipient keys encrypted using RSA-OAEP. AES is an extremely safe (including quantum safe), NIST compliant, symmetric encryption algorithm.

    Every time a document is created, a random 128 bit key (256 bit when we upgrade to AES256) is generated and used for encryption. Each user approved recipient of the data is issued a copy of that key which is then in turn encrypted with that recipients public, 2048 bit RSA key. This means that the recipient can download the data, decrypt the content encryption key (CEK) with their private key and then use the CEK to decrypt the content.

    You, the user, has a decryption key of your own which is stored on your phone. Using this, you can at any time revoke privileges for any service. When this is done, the content is reencrypted with a new CEK but no copy is afforded to that service. Revoking consent basically means you change the lock and refuse to give them a new key.

    As the content of the document is updated, the CEK gets reused. This is made cryptographically safe by replacing the IV (Initialisation Vector). This means it is impossible to deduce what content (if any) changed unless you can read the actual information. This keeps the system from leaking metadata.

    All steps of the encryption/decryption process as well as generating encryption keys, are handled by the Egendata packages (node.js only at the moment but we expect to support all major platforms) sothat, even if it sounds a bit complicated, implementation is made easy. This is also a crucial security factor since it lowers the risk of implementation mistakes being made.

    But... is it really safe?

    Information security is hard. Mistakes are easily made. When information leaks, it is never because algorithms such as AES or RSA have been broken but because of errors in implementation or leaking of keys.

    A central part of our security work is publishing all code openly. If you are skilled in infosec. and/or encryption, you are more than welcome to go through the code and help us look for vulnerabilities – we apprecieate any and all help we can get. If you submit a Pull Request we appreciate it even more :)