Sharemind MPC for embedded solutions

As seen from the Sharemind MPC introduction page, Sharemind Application Server is built in a modular fashion and meant ot be very configurable. One can choose between different storage backends (tabledb, keydb) and different protection domains that use different number of computation parties. The Application Server binary takes care of loading all the necessary modules, does session management for client applications, task management for several SecreC programs running in parallel and takes care of networking (including multiplexing several protection domain overlay networks into one TCP stream). Sometimes, however, this is too complex. There are use cases where one would just like to run a single well-defined MPC protocol between, for example, two or three static parties.

It is also possible to take a Sharemind MPC protection domain (PD) module (e.g., mod_shared3p) and invoke its MPC protocols directly from a custom code. We call this approach "protocol core" and it allows a developer to re-use our machine optimized MPC protocol implementation in ad-hoc MPC applications.

It’s possible to use a similar architecture to Sharemind Application Server that uses several computation nodes and a number of input and/or result parties. However, it also supports embedded client-server architecture (for 2-party MPC protocols):

mpc embedded architectures
Figure 1. Left: Classic application server style architecture. Right: Embedded MPC for client-server type architecture.

It’s important to understand that using the "protocol core" approach, the custom code invokes syscalls directly from within the protection domain module that expects secret-shared values. It is possible to re-use existing client libraries for this. These are the most noticeable features that are lacking in the "protocol core" approach, compared to the Sharemind Application Server:

  • No user authentication, authorization or session management. If needed, this has to be implemented according to the needs of the custom integration.

  • No networking provided. This has to be implemented according to the needs of the custom integration.

  • Existing Sharemind client applications (e.g., Rmind, CSV Importer) do not work as standard Sharemind client protocol is not used.

  • Business logic cannot be written in SecreC (there is no Sharemind virtual machine for running the bytecode).

  • No task management (there are no SecreC programs to run in parallel).

Some technical requirements to start using Sharemind protocols in custom applications include:

  • The number of computation parties must be in line with what the protection domain expects, e.g., three parties for shared3p.

  • The application should be implemented in a programming language that allows easy linking and invoking of C code.

  • You are free to choose whichever network communication library you like as long you can provide send/receive interface that is compatible with the one expected by Sharemind’s C API.