# Signing Tezos Baking Operations with Cloud Functions

MIDL.dev has been providing baking-as-a-service functionality. Today we are bringing this to a next level.

It is now possible to instantiate a new cloud baker directly from the MIDL.dev console. No more manual steps.

## Signer

We have typically been recommending our customers to run physical signers at home, connected to a Ledger device. For a private baker, this is clearly the better choice: the baker keeps physical custody of their keys, and the Ledger has built-in protections against most attacks.

However, there are scenarios where a cloud-based signer is preferred:
* corporate setup where access control is set by policy,
* absence of access to a reliable physical location.

In this case, it is possible to set up a KMS signer in a cloud environment: Amazon and Google are known to provide KMS setups.

A thin layer above the KMS translates Tezos signing requests into native KMS requests. It also ensures authentication and authorization.

## MIDL.dev Baker

MIDL.dev is providing non-custodial baking services. It runs Octez nodes and baking daemons, but the signing is done by the customer.

In the context of baking with Cloud Functions, the MIDL.dev bakers send signature requests to the KMS signer for every consensus operation (bake, preendorse and endorse).

The service is non-custodial because of the administrative boundaries between both components:

* the baking service, operated by MIDL.dev, does not hold the baking key,
* the customer's cloud account contains the KMS and therefore holds custody of the baking account.

The communication between the two services is kept secure thanks to a preliminary exchange of keys.

TBD: it could be a ssh tunnel (like the physical signers today) or JWT token based, like the channel between beacon chain and execution client on ETH.

This is not as good for decentralization as running your own baker. Indeed, the baking services are still operated by a centralized entity. But the customer holds custody, so all in all, it's better to use this service than to keep their funds on a CEX.

## Security considerations

The baker's key (and therefore funds) could be compromised by unauthorized access to the customer's cloud account or improper IAM access control configuration. As a non-custodial baking service, MIDL.dev is not liable for the customer's failure to adequately protect their cloud account.

KMS provides some security in the sense that the key can not be extracted from the hardware. However, KMS, unlike Ledger, is not Tezos aware. In particular, it does not distinguish between a consensus operation and a transfer. Therefore, anyone with direct access to the KMS interface is able to run anything, including a transfer.

We always recommend a physical remote signer with Ledger as the safest choice for baking.

Additionally, for private baking operations, we recommend putting 90% of the funds in cold storage and only keeping 10% of the funds necessary for the bond in the baker's address.

## Consensus Key

Introduced in Lima, the consensus key makes KMS baking safer. In order to use the MIDL.dev Baking service, it is required to set a consensus key that is different from the baking key.

We recommend the baking key to be held on a Ledger device, then set the consensus key to the KMS address generated on the cloud platform. At this point, the Ledger can be kept in safe storage and is only required for transfers and voting. Shall the customer lose access to the cloud account, it is possible to rotate the baker to a new consensus key.

## Signatory Cloud Functions

Cloud Functions are pieces of code that you can run on the cloud abstracted from servers and containers. The cloud platform bills in a very granular fashion, based on the computation used.

The Signatory Cloud Functions by ECAD Labs are now available. These Cloud Functions were extracted from Signatory, a trusted remote signing software for Tezos.

Their role is to translate the signing requests from the Tezos baker into a request compatible with the KMS interface. It also filters out requests, so that only consensus requests can go through.

The Signatory Cloud Functions are extremely lightweight, consisting of only NNN lines of code. This makes them easy to audit.

## How to Bake on MIDL.dev with Signatory Cloud Functions

We will provide step-by-step instructions on how to create the KMS and the cloud functions on your AWS and GCP account.

We will also provide terraform manifests for automated deployment of the aforementioned cloud resources.