Skip to main content

You are viewing Agora Docs forBetaproducts and features. Switch to Docs

Android
iOS
macOS
Web
Linux C++
Unity

Data encryption

Agora places great emphasis on the security of user data and privacy. Signaling provides TLS encryption at the transport layer and 256-bit AES encryption on the client side to effectively protect user data. Signaling is also compliant with GDPR, SOC2 Type II, and other security standards.

Understand the tech

Signaling provides the following security features:

  • Transport layer encryption: Data transmission between the client, the server, and the Signaling server is encrypted using TLS. This feature is enabled by default and cannot be disabled.

  • Message encryption: Each message is protected with end-to-end encryption after you configure the encryption parameters.

  • Token authorization: The SDK incorporates time-based access control strategies to ensure that only authorized users are able to access Signaling resources. For details, see Secure authentication with tokens.

If your application requires enhanced data security, or compliance with HIPAA or SOC2 type II standards, implement message-level encryption. Best practice is to use a combination of TLS encryption for data transmission and end-to-end AES encryption for messages.

Prerequisites

Ensure that you have integrated the Signaling SDK in your project, and implemented the framework functionality from the SDK quickstart page.

Implement end-to-end message encryption

The Signaling SDK includes a built-in AES 256 GCM encryption algorithm. To enable end-to-end encryption and decryption, simply configure the encryption mode, encryption key, and salt parameters when initializing the Signaling client instance. After encryption is enabled, the SDK automatically encrypts messages before transmission and decrypts them upon receipt, using the same encryption parameters. Your data is protected throughout the transmission pipeline. Even if a message is temporarily stored on the Signaling server, it remains cryptographically protected and cannot be accessed without the correct key and salt.

Refer to the following sample code to configure end-to-end encryption:


_15
RtmEncryptionConfig config = new RtmEncryptionConfig();
_15
// Set the encryption mode, which can be `AES_256_GCM`, `AES_128_GCM`, or `NONE`.
_15
// The default value is `NONE`, which means encryption is not enabled.
_15
config.encryptionMode = RTM_ENCRYPTION_MODE.AES_256_GCM;
_15
config.encryptionKey = "your_encryptionKey";
_15
byte[] salt = your_salt;
_15
config.encryptionSalt = salt;
_15
_15
RtmConfig rtmConfig = new RtmConfig();
_15
rtmConfig.encryptionConfig = config;
_15
// Replace your_appId with your App ID
_15
rtmConfig.appId = "your_appId";
_15
// Replace your_userId with your User ID
_15
rtmConfig.userId = "your_userId";
_15
mRtmClient = RtmClient.create(rtmConfig);

When automatic encryption and decryption is enabled, all clients under the same app ID must enable this feature and use the same encryption parameters to communicate smoothly.

Note

Automatic encryption and decryption may impact functionality in some scenarios. For instance, if you use mobile push notifications, Signaling is unable to read the mobile push keys and values provided in the message payload due to encryption. In such scenarios, only encrypt the sensitive data in the message payload and keep other data segments in plain text. This partial encryption feature may be provided in future versions of Signaling SDK.

Reference

This section contains content that completes the information on this page, or points you to documentation that explains other aspects to this product.

API reference

Signaling