The Evervault Android SDK is a library for encrypting data and collecting credit cards data on Android Devices. It's simple to integrate, easy to use and it supports a wide range of data types.
- Core encryption capabilities for various data types.
- A secure and customizable PaymentCard Compose view.
- Built-in data type recognition and appropriate encryption handling.
- Android (Api Version 26-33)
Our Android SDK distributed via maven, and can be installed using your preferred build tool.
Before using the Evervault Android SDK, you need to configure it with your Evervault Team ID and App ID. This step is essential for establishing a connection with the Evervault encryption service.
Make sure to replace
<APP_ID> with your actual Evervault Team ID and App ID which can be found in the Evervault Dashboard
Once the SDK is configured, you can use the
encrypt method to encrypt sensitive data. The
encrypt method accepts Java's primitive data types and an optional role
Here's an example of encrypting a social security number:
A role defines an encryption policy to be applied to the return ciphertext. The
encrypt function takes as an optional parameter
role which is the
id of the role created in your Evervault App
encrypt method returns an
Any type, so you will need to safely cast the result based on the data type you provided. For Boolean, Numerics, and Strings, the encrypted data is returned as a String. For Arrays, Lists and Maps, the encrypted data maintains the same structure but is encrypted (except that Arrays become Lists). For ByteArray, the encrypted data is returned as encrypted ByteArray, which can be useful for encrypting files.
Decrypts data previously encrypted with the
encrypt() function or through Relay. The
decrypt() function allows you to decrypt previously encrypted data using a token.
The token is a time bound token for decrypting data. The token can be generated using our backend SDKs or through our REST API. The payload must be the same payload that was used to create the token and expires 10 minutes after creation. The payload must be a map and the response is
Any which can, and should be, cast to
The Evervault Android SDK also provides a Compose view called
PaymentCard. This view is designed for capturing credit card information and automatically encrypts the credit card number and CVC without exposing the unencrypted data. The
PaymentCard view can be customized to fit your application's design.
Here's an example of using the
The encrypted credit card number and CVC are captured in the
PaymentCardData, as well as the expiry month and year and validation fields.
PaymentCard and its components can be customized to fit your application's design. The view excepts a number of parameters that enable you to customize the modifier, text and placeholder styles. The
content parameter accepts a
@Composable PaymentCardInputScope.() function, which can be used to customize the view's layout. The
PaymentCardInputScope components can be customized with a modifier (
Modifier), label (
@Composable), placeholder (
@Composable), text style (
TextStyle), and input field colors (
Two build-in layouts are provided:
InlinePaymentCard(the default layout) - This layout displays the card number, expiry and CVC fields inline.
RowsPaymentCard - Displays the credit card number on a single row. Below it, places the expiry and cvc fields next to each other.
You can also customize these layout through theming and modifiers:
If these two layouts do not fit your application's design, you can create your own layout by passing a
@Composable function to the
content parameter. The
@Composable function will receive a
PaymentCardInputScope (together with the
Modifier) object, which contains the
CVCField fields. You can use these fields to create your own layout:
The Evervault Enclaves SDK provides an accessible solution for developers to deploy Docker containers within a Secure Enclave. It enables you to interact with your Enclaves endpoints via standard HTTPS requests directly from your Android applications. A key feature that enables this is the attestation verification performed before completing the TLS handshake. For a deeper understanding of this process, you can explore our TLS Attestation documentation.
The attestation verification is executed using a custom Trust Manager on a
OkHttpClient.Builder. This Trust Manager needs initialization with an
It is crucial to ensure that the supplied PCRs align with the PCRs of the respective Enclave.
Then you configure the HTTP Client with the attestations:
Only use this client for requests to your Enclave. For all other requests, use a separate client.
If the PCRs of your Enclave change, the attestation connection will fail from all clients that are not updated with the new PCRs. The
EnclaveTrustManager is a service that can optionally be used to cache a list of PCRs that are returned from an API under your control. The
EnclaveTrustManager can be used by passing a
PcrCallback and the
enclaveName as a parameter to
AttestationData that is used to build the
EnclaveTrustManager will cache the response PCRs from the
PcrCallback and refresh them at a default interval of 5 minutes. This refresh can be configured by passing the
This example below show how to call an endpoint that returns a list of PCRs as the callback function.
The endpoint returning the PCRs must return the PCRs in the format
The Evervault API exposes an endpoint to retrieve the PCRs for all active versions of your Enclave which you can use to keep your clients in sync with your Enclave across deployments.
- It's crucial to note that the PCR values associated with a Enclave change with each new deployment. Consequently, older versions of your app with hardcoded PCRs may stop functioning. To alleviate this, you can accommodate previous deployments by providing multiple
PCRsobjects or use the
EnclaveTrustManager by passing a
PcrCallback to the
AttestationData allows you do update your PCRs remotely via an endpoint you control. When a Enclave is deployed and the PCRs change the list of PCRs returned from the endpoint should expand to hold the new PCRs e.g
EnclaveTrustManager will cache the new PCRs and old PCRs. Over time you can then remove the old PCRs from your endpoints response leaving just the new PCRs.
This allows for the updating of a Enclave without having to re-publish your client with new PCRs.
- Please be aware that the Android SDK is compatible only with Enclaves that have the API Key Authentication set to
falsein your enclave.toml file:
Only use the
OkHttpClientconfigured with the
AttestationDatafor requests to your Enclave. For all other requests, use a separate client. If you have multiple Enclaves, you will need to configure a separate
OkHttpClientfor each Enclave.
When calling an endpoint of your Enclave, use make sure you do not have any underscore
_in the request url. Replace any underscore, such as the one in your App ID, with hyphens
These considerations are essential to remember for a seamless integration and operation of the Evervault Enclaves SDK in your Android applications.
The Evervault Android SDK Package includes a sample app, located in the
sampleapplication directory. The sample app demonstrates various use cases of the SDK, including string encryption, file (image) encryption, the usage of the
PaymentCard view with customized styling and how to contruct an attested Enclave client.
The sample app is released under the MIT License. See the LICENSE file for more information.
Feel free to experiment with the sample app to understand the capabilities of the Evervault Android SDK and explore different integration options for your own projects.
Bug reports and pull requests are welcome on GitHub.
Questions or feedback? Let us know.