Encryption is one of the main technical features that preserves a MySudo user’s control over their personal information and protects that information from unauthorized use. The encryption in MySudo is powered by the Sudo Platform services working in combination with the Sudo Platform SDKs built into the MySudo application. 

Encryption is the act of encoding data to render it unintelligible to someone who doesn’t have the authorization to access the data. Once data is encrypted, only authorized parties who have an appropriate ‘key’ can read or use the data. How difficult (processing time and computational complexity) it would be for an adversary to guess the encryption key determines the encryption algorithm selected.

Encryption approaches employed in MySudo fall into two broad categories:

1. Symmetric key encryption: The same key is used to encrypt and decrypt the data. Due to the speed of encryption compared to asymmetric approaches, symmetric key encryption is typically used for encrypting larger amounts of data. A commonly used symmetric encryption standard is Advanced Encryption Standard (AES). The confidentiality of the encrypted data is only as good as how well the key is protected from unauthorized users.
2. Asymmetric key encryption: Asymmetric key encryption, also known as public key cryptography, generates keys in pairs—private key and a public key. Each pair of keys has two powerful properties: 
   1. Data encrypted with the public key can only be decrypted by the private key (and not even the public key). This property makes public key cryptography ideal for applications requiring the secure and private delivery of data to a recipient.
   2. A digital signature created with the private key can be verified with the public key. This property allows public key cryptography to be used for strong authentication.

Encryption technology (cryptography) is based in mathematical techniques to transfer input data to a different output. In this article, we don’t go into the mathematics because we don’t invent our own cryptography (here’s lots of reasons why). Instead, in this article we will dive into how industry standard, proven encryption algorithms and techniques are composed in MySudo and the Sudo Platform to achieve the data protection objectives that matter most to our customers. In most cases, encryption is used in multiple layers to protect data in complementary ways against different threats—this is the security principle knows as defense in depth.

Data is encrypted by service infrastructure when stored

When data is stored in databases and other data stores (such as object stores) in the Sudo Platform services, those data stores are configured with their encryption-at-rest option enabled, ensuring that data is encrypted using AES-256 symmetric key encryption. The encryption keys are stored separately in some of the most secure locations in our cloud services provider’s (Amazon Web Services) infrastructure. This encryption approach protects the data if the physical or logical storage devices are compromised and the data is accessed via the cloud services provider, as the data cannot be decrypted without access to the encryption keys.

Data is encrypted in transit

When MySudo calls the network APIs in the Sudo Platform services, the communications channel is always encrypted with Transport Layer Security Version 1.2 (TLS 1.2) or higher. Older weaker protocols such as SSLv3, TLS 1.0 and TLS 1.1 are not used. This provides protection against interception and network sniffing for all data as it passes through networks between client devices and the Sudo Platform services, whether or not individual data items are further encrypted (see ‘User specific data’ below).

The Sudo Platform services are deployed with TLS certificates that are written Certificate Transparency logs. This allows client applications using Sudo Platform SDKs to validate that they are only communicating with authentic instances of Sudo Platform services.

User specific data is encrypted within Sudo Platform

The broad, system-level data encryption described so far is a good start but is really considered the minimum that any modern application should use. The focus of the data encryption design in MySudo is the additional protection of user specific data; that is, data that should only be visible to a single MySudo user.

Below are examples of how user specific data is encrypted for a selection of MySudo capabilities. What is common across these examples is that the data is encrypted using AES-256 symmetric keys that are generated using a device or system’s secure random number generator. What varies across these examples due to practical differences between the MySudo capabilities is where the encryption key is created and how that encryption key is protected from unauthorized access. The table below summarizes the approaches to protecting the encryption key for different MySudo use cases.

Open communications: incoming SMS and email

When data is received for a MySudo user from external services, such as incoming SMS messages or out-of-network email, it is immediately encrypted in the service using a unique, random, per-item symmetric AES-256 data encryption key (DEK). This per-item key is then encrypted with the user’s public asymmetric key and stored in the Platform for retrieval by the MySudo user, after which the plaintext DEK is discarded. This ensures that only the user can decrypt the stored data, by using their asymmetric private key on their device to decrypt the DEK, and then using the DEK to decrypt the data.

Open communications: outgoing SMS and email

When data is sent to external services, such as outgoing SMS messages or out-of-network email, the message needs to be delivered in plain text to the external service provider. This is a constraint of open communications, since regular SMS, for example, does not have encryption in its design. Once the message is delivered, the message is immediately encrypted using a unique, random, per-item symmetric AES-256 data encryption key (DEK). This per-item key is then encrypted with the user’s public asymmetric key and stored in the Platform for retrieval, after which the plaintext DEK is discarded. This ensures that only the MySudo user can decrypt the stored data, by using their asymmetric private key on their device to decrypt the DEK, and then using the DEK to decrypt the data.

Private browser: configuration settings

Data that does not need to be processed in plain text by Sudo Platform or any external service is encrypted on the MySudo user’s device using a unique, random AES-256 symmetric key for each type of setting, after which the data is stored in the Sudo Platform. This approach facilitates synchronization of user data across multiple devices. Examples of this data might include Sudo profile attributes (e.g. name, avatar), browser ad/tracker blocker settings and browser bookmarks.

Secure communications: encrypted messaging

Messages and email that are sent and received between MySudo users are end-to-end encrypted so that only the users in the conversation can decrypt the messages. In preparing a new message to be sent, the sending device generates a unique, random symmetric AES-256 data encryption key (DEK). The DEK is used to encrypt the message and is then encrypted with the public asymmetric key of each of the recipients. The recipients can then decrypt the message on their device by decrypting the DEK with their private asymmetric key and the message itself with the DEK. 

If the recipient is offline, the Sudo Platform service also provides a store and forward capability ensuring that encrypted messages can be retrieved when they do come online.

Planning for the future

We recognize that security standards evolve and that the industry recommendation for minimum key lengths, preferred algorithms will change. The MySudo and Sudo Platform security designs are made with change in mind, so that we will be able to take advantage of these new security standards in the future.

Read more in the Sudo Platform documentation.