The following story explains the business need that gave birth to ok2cry. It shows why the need will continue to increase.
A fintech company wanted to offer credit cards to its customers over the loan product that they offered. In the modern manner, they outsourced the credit card management to another company. This kept them out of any regulatory controls which keeps costs and risk to a minimum. It offered an efficient way to quickly launch this new option and make their product more valuable and desirable to customers.
The fintech company were using state-of-the-art cloud services to run their operations and manage customer access using Multi-Factor Authentication (MFA).
The security for the API company was also up to standard. They always used HTTPS. They required every message to be signed with a HMAC based on an API key and secret. The HMAC was cryptographically sound.
For some specific and sensitive messages, they mandated an additional token. These cases involved sensitive card data:
- its 4 digit PIN (getting and setting)
- its full number (PAN) and code (CCV).
The token used in these cases was generated by the API company, once per card, when the card was created. The token was stored within the Cloud secret manager.
The need to collect secret data from the client did give rise to some questions over how to secure secrets but overall the security story is as good, if not better, than one can expect.
The sensitive cases pose a risk of data leakage that are impossible to close without some additional measures.
In both cases, and because the product was composed of several products from independent parties, this sensitive data is visible within the fintech company's cloud environment in plaintext until the message leaves for the client over HTTPS.
This is not ideal and is less ideal than more traditionally constructed companies. In a world where all the products are provided by one monolithic provider, like a traditional bank, the connection from the single company and the end customer can be fully end-to-end encrypted.
The API ecosystem is growing and the pressure to reduce banks and other traditional institutions into component parts is strong.
In the above example the API company outsources the production of plastic cards to another company. The plastic card company buys parts, such as the secure card chip, from another company.
This separation of responsibilities, the complex and "just-in-time" supply chains that emerge and increasing specialisation are hallmarks of the modern manufacturing economy.
The API ecosystem is providing the same kind of supply chain composition that, for example, automakers have enjoyed for so long to the service industries.
The traditional model for business trust is a legal contract to define the goods, pay for the agreed goods and a presumed willingness to litigate by both parties. This framework is used in the digital world but the nature of digital commodities are more abstract by nature.
Car manufacturers may take actions to litigate its component suppliers for faults, but mostly they try to ensure that only high quality components enter the supply chain. This is because their reputation sits atop of the supply chain, and it's ultimately they who will suffer the consequences of failure. Manufacturers typically research new parts themselves and only outsource well-understood, testable and fully designed components.
The same model of owning innovations and outsourcing commodity parts is at the heart of the API economy. Many digital part suppliers can make a good business doing one thing well and build a reputation for high quality.
This composition of parts also requires trust in the digital world. This is currently centred around HTTPS and TLS which cover a huge amount of the ground. But there are gaps or cracks in the digital pipelines as we see between the API company and the fintech company where highly secure data is revealed midway through its journey.
Why do these gaps appear? One reason is that the various parties cannot agree on a common product or standard to manage keys. The parties cannot converge on a central mechanism for managing private keys that are used to encrypt / decrypt material end-to-end.
In the digital API economy, the API company does not always have a direct communication with the client. The composing company wants to add value and therefore usually has some form of proxy that can do a mix of straight-though calls, aggregations and transformations.
If you have breaks between the API and the client, these cryptographical gaps or clear text zones are inevitable.
To share end to end cryptography the companies need to agree on some shared infrastructure and standards. Here is a non-exhaustive list:
- Key Management System: if they all live on AWS, they can use Amazon KMS. Many APIs live on GCP or Azure, and then it's not so simple to gain agreement.
- Key signing algorithm: RSA or ECDSA?
- Key strength: 256, 384 or 512?
- Key serialisation: there is a standard (PEM) for public key serialisation so there is some good news! DER is the binary standard, so it's not completely straightforward.
The companies have to discuss, agree and implement these choices. And this is for just one service composition. Things get more complicated as the messages flow across and between multiple services and providers. The conversations have more parties and become more difficult to settle and converge on a single agreed solution.
Bottom line: the cost of establishing and maintaining end-to-end trust is too high for establishing end-to-end security for a multi-party service.
In short
- a simple mechanism to ensure end-to-end encryption using disposable keys.
- libraries to produce standard cryptographic keys on clients and servers.
- a server side cache to ensure key disposal.
In more detail...
One part of the answer to end-to-end encryption is to reduce the degree of business and cryptographic trust that is needed by all parties to come to an agreement. ok2cry keys are per message exchange which means that they are short-lived and low value.
Another important part is that each player in the system will, while performing all due diligence, trust the party that they call. These are non-exhaustive examples of trust:
- The user trusts the fintech company to keep their data safe and free from corruption.
- The fintech company trusts the card API company to maintain a proper ledger of transactions.
- The fintech company trusts AWS to maintain its data in S3 or DynamoDB.
- The card API company trusts Visa and MasterCard to authorise / manage payments correctly and report transactions.
- The card API company trusts the plastic card manufacturer to put the PIN on the card and not leak it out of the chain.
This means that public keys can be sent from one end of the transaction to the other, to enable end-to-end encryption, on the basis of transitive trust.
Usability is improved when we reduce the number of decisions that need to be made, by the companies and their developers.
The ok2cry defaults and the policies that they derive from must be well documented, have clearly demonstrated efficacy and enjoy broad industry support.
Finally, ok2cry is open to extension by all parties to compose with their existing key management systems and identity management systems
Some examples are:
- A signed JWT along with the ok2cry public key. This can be validated by the OIDC server.
- A signature of the ok2cry produced public key by the identity key. This can be validated by the identity server.
- JSON schema for enforcing the contents of the messages
- the digests of the hashes can be used to ensure that they conform with supported schemas
- Additional keys can be used to gather data from third parties that is not to be shared with the client. [ Those keys must have a shorter TTL than the client key or the message will not be readable by the client. ]
How does ok2cry address each of these concerns and needs?
- Zero trust cryptography:
- each key is produced for the lifetime of a single message.
- there is no private key to manage - only to destroy.
- Transitive business trust:
- developers can combine and compose ok2cry keys within the chain of calls and separate business data and client data.
- Good defaults:
- ok2cry has one option "STRONG". The keys produced today use ECDSA and a key length of 256 with PEM for serialization.
- the ok2cry key creation policy is open source and can evolve.
- Extensibility:
- the keys can be used to protect other security elements within the payload such as JWTs or signed data.
- this enables one or more of the parties to add additional security components as they need or wish.
The biggest trust aspect that companies need from ok2cry is the inverse of the standard question: it's not "how do you protect private keys?" but "how do you assure the destruction of private keys?"
The ok2cry key cache is an ephemeral, RAM only, store. It is a specialist cryptography key cache with a strict TTL.
Customer keys are encrypted with other keys that are from an internal ok2cry service stream with a slightly longer TTL.
ok2cry is disposable keys all the way down.
One deployment option is XTDB. Data can be deleted but an audit trail s produced of its existence and deletion
https://docs.xtdb.com/language-reference/datalog-transactions/#evict
We will use AWS/Azure/GCP attestation CPUs to prove that cache is behaving according to its source code
https://aws.amazon.com/ec2/nitro/nitro-enclaves/
You don't have to trust cloud vendors: you can run the code on a blockchain and rely on NFTs to endorse the code provenance and behaviour.
We will create an NFT for each release on a public blockchain (Cosmos or other eco-friendly option TBD).
We will never put keys on the blockchain - instead we will add evidence of our code provenance and behaviour which is low cost to compute and verifiable.
This is the same hash of the distribution that the attestation CPUs will use.
All the code will be open source and all commits be signed.
The architecture of the system will be well documented and designed to use very few, well understood components. Each component has a trusted provenance and a very specific role in the system.
The developer's signing keys will be published at keybase.io. Each key is linked to Github for user verification and endorsed by the team to define a web of trust for shared responsibility.
Comprehensive internal reviews, tests and CVE scans will be conducted daily to ensure that we do not miss any failures or newly discovered vulnerabilities in any of the very few components that comprise the system.
The above data is combined into a large provenance data set that is signed for each release. Yes we do use KPI and think that it's valuable for this use case.
These components are subject to professional code audits and penetration tests.
We will make a responsible disclosure program for any exploits as well as a bug bounty program to encourage the community to share any failure cases.
Add xtdb option