Skip to content

Latest commit

 

History

History
145 lines (99 loc) · 9.1 KB

crypto.md

File metadata and controls

145 lines (99 loc) · 9.1 KB
Raw

Highlevel cryptographic process description

Entities

  1. Client ($C$):
    • Private Key: $C_{{priv}}$
    • Public Key: $C_{{pub}}$
  2. Bank ($B$):
    • Private Key: $B_{{priv}}$
    • Public Key: $B_{{pub}}$
  3. Witness ($W$):
    • Private Key: $W_{{priv}}$
    • Public Key: $W_{{pub}}$
  4. Hardware Security Module (HSM):
    • Stores $C_{{priv}}$ and offers APIs for ${hsmSign}_{hsmtoken}(message)$ and ${hsmDecrypt({message})}$ for the Witness.
    • It does not offer encryption with $C_{priv}$.
    • Only the Witness holds a secure token to access above functions.

The witness role

The EBICS Specification does not enforce encryption of the payload (bank statements). Therefore the client is able to change for example balances and create a valid proof the data. We use the concept of a witness (could also be named as signing proxy), which interacts with the bank on the clients behalf without knowing the private key of the client. The witness uses an HSM (Hardware Security Module, e.g. Google HSM) secured by a token to sign messages for the client and exchange data with the bank.

EBICS standard plans the signing of the payload, which would make the witness superluss. The schema-definitions already contain a placeholder, but they are deactivated using 'maxOccurs=0' which leads to a failure of schema validation if the signature of the payload is added to the EBICS-Response.

Snippet of 'ebics_orders_H005.xsd', which is part of the EBICS the schema-specification for their XML documents which are exchanged between Client and Bank:

<element name="SignatureData" minOccurs="0" maxOccurs="0">...</element>

EBICS Encryption and Decryption Process

All messages between Client and Bank are singed XML documents. The payload is encrypted with a symetric key, which is encrypting it with the Client's public key.

Process Description when downloading payload data

  1. Symmetric Key Generation: A symmetric key ${SymKey}$ is generated by the Bank to encrypt the payload.
  2. Payload Encryption: The payload is encrypted using a newly created symmetric key: ${Encrypt}{SymKey}({Payload}) \rightarrow {Payload}{enc}$
  3. Symmetric Key Encryption: The symmetric key (SymKey) is then encrypted using the Client's public key, $C_{{pub}}$. This ensures that only the holder of the corresponding private key can decrypt and use the symmetric key. Encrypted Symmetric Key: ${Encrypt}{C{pub}}({SymKey}) \rightarrow {SymKey}_{enc}$
  4. Create EBICS Respose: After a client sends an EbicsRequest, the Bank ready to sign and send an EbicsResponse which contains ($|$ denotes concatentation): ${ebicsResponse} = {Payload}_{enc} | {EncryptedSessionKey} | {XMLSignature}$

Process Description with Witness and HSM

To work on the Clients behalf, the Witness needs to sign messages for the banking backend, for example it needs to create a singed EbicsRequest message, in order to get the EbicsResponse message which contains the payload containing balance and transactions:

To sign messages for the bank it uses :

  1. Request and Download EbicsResponse Using the HSM, the Witness is able to create the EbicsRequest by signing it with the HSM: ${hsmSign}{hsmtoken}(EbicsRequest) \rightarrow {sign}{C_{priv}}({EbicsRequest})$
  2. Sign Encrypted Payload Witness creates signature of encrypted payload:
    ${Signature}{w{priv}} = {Sign}{W{priv}}({Payload}_{enc})$

ZK proofing system

Process Description

The Witness uses hyperfridge and the HSM to create a SNARK proof with:

  • ${Payload}{enc}, {SymKey}{enc}, {XMLSignature}$
  • ${Signature}{w{priv}}$
  • And decrypted transaction key ${SymKey}$ by calling $hsmDecrypt_{hsmtoken}(Symkey_{enc})$ which is needed to speed up the proof-generation.
  1. Create STARK Proof: ${ZKProof}_{ImageID}({PrivateInput}, {PublicInput}) \rightarrow {Commitment}$

    • Private Inputs:

      • Extracted from ${EbicsRequest}$:
        • ${Payload}_{enc}$: Encrypted payload, decrypt payload with ${SymKey}$ to extract the commitments.
        • ${SymKey}_{enc}$: Encrypted symetric transaction key, assert that the HSM-decrypted symetrical key is identical to the symetrical key of the document.
        • ${XMLSignature}, {}$: Signatures by the bank cover ${SymKey}$
      • ${Symkey}$: Decrypted symetric key which is used for speeding up decryption of ${Payload}$ and integrity check for the $Payload$

    • Public Inputs:

      • IBAN, $B_{pub}$, $W_{pub}$

    • Commitment: Public input and data from $Payload$ and $EbicsResponse$: ${extractCommitment}({EbicsRequest}, {Payload})$ presented as a JSON document embedded in the Risc-Zero STARK data structure.

The STARK presents a proof of computation. The computation is sealed (using Risk-Zero framework) and has following properties:

a. Validate $SymKey$: The Bank has generated $SymKey$ to encrypt the $Payload$ (clients data)

  • Verify $XMLSignature$ which contains $Symkey_{enc}$.
  • Decrypt $Symkey_{enc}$ with $C_{priv}$ which proves the document was sent to the specific client.

b. Validate integrity of $Payload$:

  • Validate ${Signature}{w{priv}}$ of $Payload$ so the client is not able to tamper the $Payload$ to present a fake balance.

c. Create commitment from decrypted $Payload$:

  • Decrypt $Payload$ with $Symkey$.
  • Extract the data from payload and create the commitment.
  • Add public input to the commitment.

d. A seal for the proofing algorithm - the STARK based on an $ImageID$

Verification

  1. Verification using Risk-Zero Receipt: Other parties (like the Bank or external verifiers) can verify the zero-knowledge proof.
    • Verify proof with: ${VerifyZKProof_{ImageID}}() \rightarrow Commitment$.
    • Check the public input (IBAN, $B_{pub}$, $W_{pub}$).

(8.) On-Chain verification with Groth16 SNARK:

Key Benefits

  • Privacy: The Client's private key remain confidential throughout the process. No party has access to any of the others private keys. The witness is not able to see the payload.
  • Security: The signature from the Witness and the zero-knowledge proof mechanism ensure the security and integrity of the transaction without compromising sensitive information (transaction data).
  • Verifiability: External parties can verify a bank statements legitimacy without accessing private keys or sensitive transaction details - on-chain or off-chain.
  • Automation: A TradFi transaction becomes a "signal" which can be presented, processed or triggered on any blockchain, fully automated.

Security Considerations

  • The witness also acts as a signing proxy to create the $EbicsRequest$ which is necessary to trigger the download of $EbicsResponse$ which contains the $Payload$. Witness and Client together are able to create fake proofs.
  • The zero-knowledge proof allows the Client to prove knowledge of certain information without revealing the information itself and without violating the privacy of financial data.
  • The use of digital signatures by the Witness ensures the integrity and authenticity of the payload, which might not be necessary if the Ebics Standard implements its planned feature and will actually sign its payload.
  • The HSM must be tamper-resistant and capable of securely managing cryptographic keys and operations.

Execution time

See here.

Outlook and use cases

Proof transaction inclusion and Instant Payments

As we are able to prove the payload, we can create a proof for transaction inclusion. Means we can prove FIAT payments incoming and outgoing, both on-chain - similar to how cross-blockchain bridges work today. Most banks are operating on a daily basis which prevents interactive use-cases or would ask e.g. for optimistic implementation and addition funds to secure the FIAT bridge. But the EU (European Union) is working on instant payments which would even allow instant interactive and non-interactive applications. This does not only apply to FIAT assets but also to any TradFi assets. For example, Maker DAO has invested 400 mUSD in a Blackrock ETF for traditional assets. Hyperfridge would be able to create proof of assets and do balancing of investments (invest and divest) automatically. Note that using Ebics and standard banking functionality comes at no cost or transaction fees.

Open-API Banking and Payment-API (e.g. Stripe)

The principles presented here can be applied to other Open Banking Standards as well like India's UPI or the PSD2 standard. Integrating payment platforms like Stripe would add fees to payments but is widely used. Payments on Stripe are easy to set up and may be processed withing a few minutes which makes interactive use cases possible.

Witness, HSM and other secure modules

The Witness for hyperfridge needs an HSM to sign data. One might think of Apple Secure Enclave to enable new use cases where a simple Phone or Laptop can act as a witness.