Encryption flows

Message encryption

We follow the JWE spec:

DIDComm Messages are encrypted with the keys of a single DID. A message being sent to multiple DIDs MUST be encrypted for each DID independently. If a single DID has multiple key types, the keys of each type must be used in a separate encryption of the message.

DIDComm supports two types of message encryption: Authenticated Sender Encryption (“authcrypt”) and Anonymous Sender Encryption (“anoncrypt”). Both forms are encrypted to the recipient DID. Only authcrypt provides direct assurances of who the sender is. Each encrypted message MUST use either authcrypt or anoncrypt.

The encrypted form of a JWM is a JWE in General JSON Format. The JOSE family defines JSON Web Algorithms (JWAs) which standardize certain cryptographic operations that are related to preparing JOSE structures. For the purposes of interoperability, DIDComm messaging does not support all JWAs; rather, it takes a subset of the supported algorithms that are applicable for the following cases around secure messaging. These supported algorithms are listed in tables later in the spec.

ECDH-1PU for key wrapping
XC20PKW for data encryption
X25519 for in-memory key encryption

Data encryption

Data is encrypted using AWS KMS and SSE-S3.
Encryption / Decryption operations are managed, logged, and monitored within AWS.
Data at rest in AWS is encrypted using ECDH-1PU+XC20PKW.
Data in transit is encrypted using TLS 1.2 or greater.

SafePII

Notabene adds a new PII service to our Travel Rule nodes. This industry-first feature allows VASPs to manage the secure exchange of encrypted PII to counterparties while simultaneously managing their own encryption keys.

As a separate first-class service run on behalf of our clients, SafePII is next to but complementary to our existing Travel Rule Service API. Separating this critical part of our API will allow VASPs to take a risk-based approach to better implement the Travel Rule from a data protection point of view. The escrow aspect of our service will enable us to perform address ownership and proprietary Notabene rule-based checks before encrypted PII is exchanged with the beneficiary VASP.

Encryption keys are, by default, managed by VASPs themselves. Still, VASPs can elect to utilize our key management infrastructure for some or all aspects of their service, similarly to how VASPs use a combination of local hot wallets and custodial wallet API services today. Unlike wallet API services, we explicitly designed our SafePII service around data encryption.

Regardless of how VASPs choose to use our SafePII service in the future, it is a considerable step up in data security over building your own service to integrate with an existing Travel Rule protocol. It also signals to counterparty exchanges that you take the data protection duties of implementing the Travel Rule very seriously.

Based on their needs, VASPs can choose between three different options:

End-to-end
Hosted
Hybrid

If you want to use the End-to-End or Hybrid flows, you must utilize our SDK.

End-to-end encryption

End-to-End SafePII brings the most security, as the Originating VASP encrypts PII data so that only they and the Beneficiary VASP can decrypt it.

In this flow, PII data traveling across the ether will be encrypted, meaning Notabene will never have access to the contents. Even in a hacking case or a leak, the attackers will not be able to decrypt the PII data because it’s simply cryptographically “impossible” – unless they can figure out the decryption key, which is only known by either of the VASPs.

This is how end-to-end encrypted data will be displayed in UI:

Hosted encryption

During the Hosted SafePII flow, Notabene encrypts all raw Travel Rule transaction data created through our easy-to-use restful API without worrying about local key management. Each VASP has a dedicated encryption key managed by Notabene’s PII service and can be rotated on-demand.

The Hosted flow is beneficial for VASPs using hosted/white-label exchange software and/or VASPs that don’t feel comfortable managing encryption keys by themselves.

Hybrid encryption

The Hybrid SafePII mode extends the End-to-End flow, where the Originator VASP further encrypts the PII data selectively using their dedicated Notabene-managed encryption key, allowing Notabene to decrypt the PII (or parts of the PII data) for in-flow pre-transaction name sanction screening.

More information

At its core, our new SafePII service is built entirely using open standards and libraries. We believe it is important not to reinvent the wheel, particularly regarding encryption. Our goal is to push some of the learnings we have made here into Travel Rule protocol groups and provide our core encryption libraries as open source.

The Notabene Travel Rule Network is built on top of the W3C standard of Decentralized Identifiers (DIDs), co-authored by two of our Notabene co-founders. Our new SafePII service utilizes the DID-Comm standard for securely exchanging encrypted and authenticatedmessages between entities such as VASPs.

Click here to learn how Decentralized Identifiers (DIDs) are shaping the Crypto Travel Rule infrastructure.

This set-up, in turn, is based on long-time industry standards for encryption JSON Web Encryption. We use the EdDSA encryption algorithm by default, which is currently recognized as the most secure public key encryption algorithm. We can easily upgrade to newer, better protocols in the future.

When encrypting a data item, an entirely new key is generated and encrypted to VASP’s public keys, encrypts the data, and is discarded. This ensures that even if bad actors could decrypt a single data item using massive national government-grade computing power, they will only be able to crack that specific data item–nothing more.

All data is additionally hashed and only identifiable by a content addressable identifier (CID) which stems from the InterPlanetary File System (IPFS) ecosystem. Knowing a CID is not enough to access the data; the client must be authorized and authenticated by the owner(s) to gain access. Typically the owners are the Originator & Beneficiary VASPs, but it could also be an intermediary such as Notabene.

CIDs are useful as VASPs can use them as consistent internal identifiers of PII without exposing the risk of actual PII within their own services.

Additional Security considerations:

In the End-to-End and Hybrid SafePII flows, VASPs encrypt PII data to each other using their self-managed keys.
VASPs publish their respective public keys on the Notabene VASP Network for key discovery.
VASPs can rotate their self-managed keys by generating a new cryptographic key pair and publishing the public key on the Notabene VASP Network.
PII service-managed keys (for hosted & hybrid flows) can be rotated on demand.
Used encryption keys must comply with the new W3C “did:key” spec.
‍