Security controls have been designed into DittoKit from the beginning. All communications are consistently protected by strong and modern encryption, whether it is via the Internet or via Bluetooth. Cryptographically-signed business rules ensure users can only sync data that they are permitted to access. The app developer is in complete control of the keys, certificates and rules.

Encryption: TLS 1.3 Authentication: EC keypairs with signed certificates Trust infrastructure: X.509 with a developer-controlled certificate authority


Every installation of an app that uses DittoKit has its own identity. When you start prototyping with Ditto you can use a development identity, which contains default settings and offers no real security. Once you are ready to deploy, this can be swapped for a production identity where security is enforced.

An identity is a bundle of device and app-specific information:

  • Site ID - A number unique to this device.

  • App Name - A name identifying the application. This avoids different DittoKit-enabled apps trying to sync with each other. Like iOS App IDs, this takes the form of a domain name. Example:

  • Access Rules - Define which documents this device is allowed to read or write during sync.

  • Private Key - A secret for authenticating as this identity.

  • Identity Certificate - A certificate verifying the particulars of this device, signed by the CA.

  • CA Certificate - Used to verify certificates presented by other devices with the same app.



Site ID

Allocated by central authority

Defaults to a random number;

can be customized

App Name

Set by central authority

Defaults to "";

can be customized

Access Rules

Set by central authority

All devices may read/write all documents

Private Key

Either generated on device,

or distributed by central authority

Hard-coded and shared by all devices

Identity Certificate

Unique and signed by central authority;

contains this device's public key

Hard-coded and shared by all devices

CA Certificate

Shared by all users of the same app

Hard-coded and shared by all devices


DittoKit identities and public keys are distributed in the standard X.509 certificate format. They do not directly contain potentially sensitive data such as access rules.

DittoKit does not commit you to any workflow for managing identity data and certificates. When you are ready to start using production identities, contact the Ditto team and we will help you set up the right CA tooling for your use case - or provide specifications so you can build your own.

App-level Security

The access rules contained in the identity are rigid, signed by the central certificate authority and enforced by all participating devices. This offers the highest level of security. If a person is not allowed to access particular data, it will never be synced to their device.

For apps with weaker security requirements a developer may choose to relax the access rules for Ditto, then restrict access in their application code.

One advantage is that the developer has more flexibility to change the access rules dynamically, since they are not encoded in signed certificates. Another advantage is that all devices in the mesh can participate in syncing the data, which may help it propagate faster. If certain data is only accessible to a few privileged devices which are not often in range of each other, it will take longer for them to sync.

The disadvantage is that an unprivileged user does have a device containing privileged data. A technically savvy user or phone thief may be able to gain access to not only their regular data, but also the more privileged data that they were never intended to able to view.

Therefore relaxed access rules - app-level security - are only suitable for environments where there is a degree of trust that the devices won't end up unlocked in the wrong hands.