DEV Community: eric-capeprivacy

Hide And Seek

eric-capeprivacy — Thu, 24 Nov 2022 19:59:05 +0000

A game that we all played when we were young is probably hide and seek. When we grow up, we come up with new variants like scavenger hunt. Did you ever want to play scavenger hunt in real life but too tired to set up props? Or perhaps you can make your friends guess where you are by posting a selfie and giving hints to your exact location. I present to you, the hide and seek game. Where your browser with access to your location data, can leverage Cape to enable sharing of your secret location, without anyone but you being any the wiser.

This walkthrough shows how this application is developed using technology developed at Cape Privacy. It showcases the power of data encryption without the hassle of key management. After the walkthrough, you will have a web application that you can interact with anywhere.

Playing around with it

A example of this app has already been deployed to codesandbox.

In this web application you can click the hide button. That will encrypt your current coordinates that you can send to your friend!

Once your friend receives the coordinates, they can copy it into the destination text box and click the seek button which will tell him how far or close they are to your current location.

Why use Cape for this solution

Through the use of Cape encrypt, we could encrypt your location and allow you to share your data with someone else without them knowing where it is. This data is only accessible for the function you intend it for and can’t be accessed by anyone else. All of the overhead of encryption and key management has been handled by the SDK, making it easy to leverage for the application.

Implementation

The python source code for this project can be seen here on github.
This example is run using the Cape-JS and the function is deployed using Cape CLI.

Setup Dependencies

Make sure you have CLI installed by running:
curl -fsSL https://raw.githubusercontent.com/capeprivacy/cli/main/install.sh | sh

Create the Function

The function is relatively simple but showcases a couple of nuances in how it is invoked.

What’s interesting about the current cape_handler function is that the handler expects to take two user-provided inputs, one after the other. It will persist the first input on disk until the invocation is complete.
This allows the handler function to take an encrypted input first and a non-encrypted input after. Achieving the desired result of mixed encrypted and unencrypted inputs.

Calling this function from an external source would take on the form of:

Connect (connects to the enclave)
Invoke (send first input)
Invoke (send second input)
Close (close the connection to the invocation, resetting the state of the function)

app.py

import math
import string
from unicodedata import name
import json
import geopy
from geopy.distance import geodesic as GD


FILE_PATH = "./secret.json"


def open_secret(path=FILE_PATH):
    with open(path) as f:
        try:
            data = json.load(f)
        except Exception:
            return None
    return data


def store_secret(data, path=FILE_PATH):
    with open(path, "w", encoding="utf-8") as f:
        json.dump(data, f, ensure_ascii=False, indent=4)


# Function needs to check if the coordinates match the one that was provided.
def cape_handler(arg):
    user_input = json.loads(arg)

    # use file cache instead
    secret = open_secret()
    if secret == None:
        # Store the current input as secret
        store_secret(user_input)
    else:
        # Calculate the difference between the user secret and the current input.
        user_loco = (float(user_input["latitude"]), float(user_input["longitude"]))
        secret_loco = (float(secret["latitude"]), float(secret["longitude"]))
        distance = GD(secret_loco, user_loco).m
        if distance < 100:
            ret = f"Congrats you found the treasure!"
        elif distance < 10000:
            ret = f"Getting closer! still {distance} meters away"
        else:
            ret = f"Not even close! still {distance} meters away"
        return ret

requirements.txt

geographiclib==1.52
geopy==2.2.0

secret.json
Just an empty file that can be created by:
touch seek/secret.json

At this point the seek directory should look like:

requirements.txt
seek/
   - app.py
   - secret.json (empty file)

Before deploying this function, we have to install the dependencies with the function by calling (from the parent directory of [seek]):
pip install -r requirements.txt --target seek/

This will install the dependencies required to run the function.
Next step will be to deploy this function to Cape using the Cape CLI tool.

Deploy the Function

To deploy the function use the cape binary that has been downloaded from the CLI step and run:

cape login

This will give you a prompt to open up a browser and login to your github account.

To deploy the function run:
cape deploy seek/

You will see an output like the following:

Function ID ➜  YmoDB35PKxZS9v6eaU84YR
Function Checksum ➜  6b6d1c8b21f896269554cf633da084b25b49706a8efb41463687f353e0395171

Then run
cape token <FUNCTION_ID> --function-checksum <FUNCTION _CHECKSUM> -o json > seek.json

Interacting with the Function via the React App

To use the deployed function, we will use Cape-JS and use the encrypt and invoke methods defined through the Cape client.

To call the function from the example React App, simply update the following file to reflect the functionID and functionToken from seek.json obtained in the previous script to the file here.

Final Thoughts

This project showcases the power of Cape to share data amongst different parties in a purely encrypted format. It also showcases a workaround for stateful execution and temporary data persistence from within the enclave. These methods allow the developer using Cape SDKs to expand the capabilities of their functions and interact with them from various platforms.

Leader election in the enclave

eric-capeprivacy — Mon, 24 Oct 2022 18:54:32 +0000

Leader Election Problem

In the no-longer-as-niche world of distributed systems, there is always a fundamental problem whose solution came to be the building block of modern day massively distributed computation platforms. Of course I'm talking about consensus. Past versions of achieving this include algorithms like Paxos and Raft, which have seen much adoption in today’s distributed services. Before we get any further though let’s get some term definitions out of the way.

Transaction - A state change that needs to be broadcasted throughout the distributed network

Peer - A computer or server that participates either in generating a transaction (e.g. peer A sends some money to peer B) or validating the transaction

These algorithms may not seem like much hype outside of the fact that they form the backbone of how applications are able to handle terabytes of concurrent data, but you may have heard about Bitcoin and their Proof-of-work (POW) algorithm. At the heart of Bitcoin is a very expensive and fault-tolerant solution to the consensus problem. It has often been the complaint of many that the Proof-of-work algorithm is too costly and woefully inefficient. As a result, new consensus algorithms like Proof-of-stake (POS) have been invented to fundamentally alter how the consensus problem is solved in massively distributed open networks such as Ethereum.

Even then the chance of misconduct still remains. Each view of the transactions may not match that of other peers in the network, giving opportunity for double spending attacks until the overall system reaches eventual consistency (majority of peers agree on a state change in the system) after a couple of blocks. Since the validators are less in number the question of correct and unbiased processing of transactions.

With this adoption of POS come new challenges. The peer with more stake in the system that functions as a validator may still choose to bias against certain transactions without being penalized. One method to avoid this bias is to run part of the block generation process in a trusted execution environment, where the chosen transactions are guaranteed to be chosen fairly. We can show this via a simple leader election demo to showcase how easy it is to leverage Cape to do this.

This demo is done as part of an internal hackathon and serves to showcase how a part of the protocol can be migrated into confidential computation for more trusted output. The goal is to have the secure execution environment decide on who is the leader of peers in a network. Currently in this example we did not add fault tolerance as there is no timeout value set. For each peer started in the demo, it will try to gossip with other peers in the network and rely on Cape for determining who is the leader amongst the peers.

Why use Cape for this solution

Cape brings the power of confidential computing alongside modern day encryption to keep the data confidential. In this use case, we focus on the confidential computing aspect that Cape offers. The deployed function with Cape is validated during invocation to make sure that the function is the one intended to be called. This guarantee in execution logic is what allows for trusted output. An example of this is illustrated below.

Cape deploy returns the function checksum, if the checksum validation fails, the data is never submitted for running the function.

Implementation

A running example of this code can be seen here on github.

This example is run using the PyCape and function is deployed using CapeCLI.

Setup

Dependencies

Make sure you have CLI installed by running:

curl -fsSL https://raw.githubusercontent.com/capeprivacy/cli/main/install.sh | sh

Make sure you have PyCape installed by running:

pip install pycape

Create the function

The function is created with a public/private key pair and returns a result that is signed with the private key.

In a python environment run:

key = RSA.generate(2048)
private_key_bytes = key.export_key('PEM')
public_key_bytes = key.publickey().exportKey('PEM')
with open("private.pem", "wb") as f:
    f.write(private_key_bytes)

with open("public.pem", "wb") as f:
    f.write(public_key_bytes)

Copy the generated public and private key into a function folder with the following files:

app.py

import json
from unicodedata import name
from Crypto import Random
from Crypto.Cipher import PKCS1_OAEP
from Crypto.Hash import SHA256
from Crypto.PublicKey import RSA
from Crypto.Signature import PKCS1_v1_5

def cape_handler(arg):
    user_input = json.loads(arg)
    if "node_list" not in user_input:
        raise Exception("node list is missing")

    nodes = user_input.get("node_list")
    nodes.sort()
    message = str(nodes[-1])
    digest = SHA256.new()
    digest.update(message.encode("utf-8"))
    private_key = RSA.importKey(open("private.pem").read())
    signer = PKCS1_v1_5.new(private_key)
    sig = signer.sign(digest)
    return_val = {}
    return_val["message"] = message
    return_val["signature"] = sig.hex()
    return json.dumps(return_val)

requirements.txt

pycryptodome==3.15.0

at this point the function directory should look like this:

function/
   - app.py
   - private.pem
   - public.pem (not necessary, included for convenience later)
   - requirements.txt

Before deploying this function, we have to install the dependencies with the function by calling (from the parent directory of function)

pip install -r function/requirements.txt --target function/

This will install the dependencies required to run the function.

Deploy the function

To deploy the function use the cape binary that has been downloaded from the CLI step and run:
cape login

This will give you a prompt to open up a browser and login to your github account.

To deploy the function run:

cape deploy function/

You will see an output like the following:

Function ID ➜  YmoDB35PKxZS9v6eaU84YR

Function Checksum ➜  6b6d1c8b21f896269554cf633da084b25b49706a8efb41463687f353e0395171`

Then run:

`cape token <FUNCTION_ID> --function-checksum <FUNCTION _CHECKSUM> -o json >  leader_election.json

Running

Note the functionID and functionChecksum fields in the previous step as they will be important in getting the example working.

In your local environment copy the folder gossip from here and make sure you have this file.

Now you are ready to try out running the example by calling in two separate terminals with your deployed functionID and functionChecksum:

python start_node.py -p 5000 -n 5001 -f-fh`

python start_node.py -p 5001 -n 5000 -f <FUNCTION_ID> -fh <FUNCTION_CHECKSUM>`

This will start the gossip protocol between two peers in the local environment and have them send UDP packets with each other and print out who the leader is between the nodes. You can also add new peers and see how the algorithm works with more peers in the system.

Final thoughts

This is just a simple example of how to migrate a part of the consensus logic into a TEE for guaranteed correctness of execution. Bitcoin and Ethereum took this concept to a globally distributed peer system and found huge success. Fundamentally the value of these systems rely on generating trust. TEEs give you similar levels of execution guarantee without the need to have lots of graphics cards or lots of Ethereum.

With a more complete example in the future we can devise a more efficient consensus algorithm using TEE and showcase that the number of messages can be reduced dramatically even under Byzantine conditions.

Check out the Getting Started Docs to try Cape for free. We’d love to hear what you think.