How can we help? 👋


Client data is never exposed to DekkoSecure as the service provider when it is stored, shared, and collaborated on, delivering true data ownership and security. Public key infrastructure is used to establish secure collaboration between users, and all content is shared explicitly. This also means that client’s administrators do not have access to end-user data.

The encryption key generation and exchange process that takes place when users register and share/sign/collaborate/conference is completely transparent to users - the DekkoSecure application handles all security events automatically, meaning users can never make a mistake in securing their account or data. This also makes the onboarding process very straightforward for both internal or external parties.

Alternate services that offer encryption with “bring your own key”, enterprise certificates, or file-level passwords are highly error prone, because the security of a sharing process relies on a human (the end user or an administrator). By removing this human reliance, DekkoSecure is even more secure beyond just the encryption itself.

Security summary

  • Every user that uploads, shares and access data has an account, and all accounts have a private and public key which are generated during account creation.
  • User key generation (ECC-384) happens client-side in the DekkoSecure web application, which is done automatically for every user.
  • Private keys are encrypted by the user’s password before they are stored on DekkoSecure cloud infrastructure. User’s passwords are hashed and salted before they are stored on DekkoSecure cloud infrastructure. Public keys are also stored on DekkoSecure cloud infrastructure.
  • When a user logs in their encrypted private key is retrieved from DekkoSecure cloud infrastructure and decrypted by the user’s password.
  • User’s private keys are used to decrypt content that is shared with them.
  • A new key is generated for every file and message sent (AES-256), which is exchanged with recipients using Public Key Infrastructure.
  • File and message sharing is signed using the author’s private key, and signature checking is handled automatically during every exchange.
  • TLS1.3 secures all client-client traffic communications.
  • Disk and database encryption is applied to data at rest.

Feature-specific security

File sharing

Encryption and signing takes place before a file is uploaded and shared. Files are encrypted using the uploader's private key and an additional key (AES-256) that is unique to the file. As well as this, the file is signed using the uploader's private key when it is shared. Downloaded files are decrypted locally by authorised recipients.

Document signing

Approval files are encrypted by the DekkoSecure application (as above) and then uploaded to the DekkoSecure cloud. The in-app document viewer decrypts the file locally and presents it to the approver. All elements added to signed documents (text, images, watermarks, signature, etc.) are encrypted and digitally signed by the approving party (or parties), and automatically shared back with the requester.


Similarly to file sharing, mail and chat messages are encrypted and signed using the sender's private key and an additional key that is unique to the message. Messages are decrypted locally by authorised recipients.

Video conferences

DekkoSecure's meetings feature uses symmetric key encryption, based on a unique key that is generated when a user schedules a video conference. This key is passed to invitees via public key infrastructure, and is persistent until the meeting ends, or, rotated if an invitee is removed. This means that it is impossible for anyone who is not invited to join a meeting.


Does DekkoSecure use proprietary encryption?

No, DekkoSecure does not use proprietary encryption. The application's security model relies on industry-standard encryption mechanisms, protocols, and algorithms with a proven track record for robust security. It utilises widely-accepted standards such as AES-256 for symmetric encryption and follows established protocols for secure communication.

Data is secured and accessed by user’s keys (end-to-end encryption) rather than keys owned by DekkoSecure. This stands DekkoSecure apart from most collaboration offerings as one of the very few vendors that makes a guarantee that it cannot access customer data (along with many other security and privacy benefits!).


What is ECC-384 and AES-256?

ECC-384 is a variant of Elliptic Curve Cryptography (ECC), known for its strong security with shorter key lengths, making it preferable in resource-constrained environments.

AES-256, part of the Advanced Encryption Standard (AES) family, is a symmetric encryption algorithm widely adopted for its high-security level due to its 256-bit key length.


Where are users’ encryption keys generated?

Encryption keys are generated client-side by the DekkoSecure web application during account registration. Private keys are encrypted using users’ passwords before being stored by DekkoSecure, ensuring they are inaccessible on the server.


Where are users’ encryption keys stored?

Encryption keys only ever exist in a form that can be used by the DekkoSecure application on the user’s client device while a user is logged in. Keys are stored encrypted by DekkoSecure, and DekkoSecure as the vendor/key store has no information that can be used to decrypt user’s keys (i.e., user’s passwords).


Where does the key management take place?

All key management, including user key generation, key retrieval, content key generation, and sharing key exchange/PKI, occurs client-side within the DekkoSecure web application. Network layer (HSTS/TLS, “in transit”) and “at-rest” security (managed by Microsoft Azure for the cloud-based DekkoSecure service) are consistently enforced and complement application layer security. By way of comparison, most competing services only offer in transit and at rest security.


Does DekkoSecure use PGP?

No, DekkoSecure does not use PGP. While its security model shares similarities with PGP, DekkoSecure’s implementation is more comprehensive and offers greater security depth.


Does DekkoSecure allow BYO keys/certificates/hardware modules/etc.?

No, the DekkoSecure web application internally handles all key management processes, eliminating the need for external key and certificate systems. If you choose to host the DekkoSecure application (on-prem), your disk encryption will serve as the at rest encryption scheme.


Can encryption keys be rotated?

A user’s key can be rotated by recreating (deleting and re-registering) their account. Note: Deleting an account also erases all associated content (files, messages, etc.).

A file’s key can be rotated by deleting and re-uploading it.


Are there ‘master’ keys / can admins access or manage an organisation’s key(s)?

No. The security model of the DekkoSecure application does not utilise single keys for multiple users or files. All users have a public and private key, and every individual content item (files, messages, etc.) also have their own key. Administrators/privileged personnel cannot access content unless it is explicitly shared with them.


Can DekkoSecure encrypt my emails (sent by Outlook)?

No, DekkoSecure is not an email system and does not run in a mail client such as Outlook; DekkoSecure can be considered as a secure alternative to email. The Mail feature functions similarly to regular email, and supports attachments (with no size limit), revoke and read receipts.

Notifications from the DekkoSecure application are delivered via email (i.e., “John Smith has shared files with you on DekkoSecure”).

Example security flow

Below is a look in to how the DekkoSecure application secures a file sharing interaction:

1- Registration

Notion image

When a DekkoSecure user creates their account, an encryption key pair (public and private key) is generated on the client (the web app). The public key and a secured version of private key (encrypted using the user's password) are stored on DekkoSecure's sovereign cloud.


2 - Authentication

Notion image

DekkoSecure users are identified uniquely by their registered email address. Successful authentication requires a registered email, the correct password and (optionally) two-factor authentication. A correct password will retrieve and decrypt the user's private key which is kept in the user's browser storage until they log out.

3 - File upload

Notion image

4 - File storage

Notion image

Files uploaded to DekkoSecure are signed and encrypted using the uploader's private key. An additional encryption layer is also added using a unique key that is generated at the time of upload (ECC-384). TLS1.3 secures all traffic on top of file encryption.

Files are stored with zero knowledge, meaning there is no way DekkoSecure can access the user's files. This is made possible be the fact that we do not have access to the private key(s) which are used to encrypt them. Even if we walked in to our cloud data centre and took a hard drive out, we still couldn't read a user's files!


5 - File sharing

Notion image

6 - File receipt

Notion image

Files shared with existing DekkoSecure users are secured using end-to-end encryption by way of an asymmetric key exchange. File sharing with existing users is enforced by default, but customers are able to disable this policy. If files are shared with an unregistered address, the file key is stored securely and then passed to the user when they complete registration - after this point, all future interactions are end-to-end encrypted.


File sharing recipients are notified via email and must log in to their DekkoSecure account to view or download anything that is shared with them. The recipient's private key is used to access file and the sender's public key is used to verify the file's integrity.


7 - File deletion

Notion image

When data (or accounts) are deleted, the keys for all data subject to deletion are erased. Following this, the encrypted data is overwritten with garbage data which is then deleted again.

Did this answer your question?