SCA3S: back-end infrastructure

Acting as a component part of the wider SCARV project, SCA3S is a collection of resources that support the development and analysis of cryptographic implementations wrt. side-channel attack: SCA3A is, more specifically, pitched as offering "side-channel analysis as a service": it allows users to acquire and analyse side-channel data-sets which stem from execution of their implementation, without (necessarily) owning or operating the associated infrastructure. Mirroring the goals of SCARV, it places particular emphasis on analogue side-channels (e.g., power and EM) stemming from RISC-V-based platforms. The main repository acts as a general container for associated resources; this specific submodule houses the back-end infrastructure, which is, for example, tasked with orchestrating the acquisition and analysis of trace sets.

Organisation

├── bin                     - scripts (e.g., environment configuration)
├── build                   - working directory for build
├── extern                  - external resources (e.g., submodules)
│   ├── sca3s-middleware      - submodule: scarv/sca3s-middleware
│   └── wiki                  - submodule: scarv/sca3s-backend.wiki
└── src
    └── sca3s               - source code for SCA3S
        └── backend         - source code for SCA3S back-end infrastructure
            ├── acquire       - acquire-specific functionality
            │   ├── depo        - depository implementations
            │   ├── board       - board      implementations
            │   ├── hybrid      - hybrid     implementations (i.e., "merged" board + scope)
            │   ├── scope       - scope      implementations
            │   ├── driver      - driver     implementations
            │   └── repo        - repository implementations
            ├── analyse       - analyse-specific functionality
            └── share         - shared           functionality

Quickstart

1. Install any associated pre-requisites, e.g.,

   • a Python 3 distribution,
   • a suitable compiler and programming tool-chain, e.g., board-specific versions of GCC and OpenOCD,
   • a scope-specific driver, e.g., offering a specific API for some PicoScope oscilloscope,
   • the Doxygen documentation generation system.

2. Execute

   git clone https://github.com/scarv/sca3s-backend.git ./sca3s-backend
   cd ./sca3s-backend
   git submodule update --init --recursive
   source ./bin/conf.sh

   to clone and initialise the repository, then configure the environment; for example, you should find that the environment variable REPO_HOME is set appropriately.

3. Perform various preparatory steps:

   1. Create and populate a suitable Python virtual environment based on ${REPO_HOME}/requirements.txt by executing

      make venv

      then activate it by executing

      source ${REPO_HOME}/build/venv/bin/activate

   2. Write a configuration file, which captures the static configuration of the acquisition appliance, e.g., by updating

      ${REPO_HOME}/example/conf/example.conf

      so the database of hardware (namely board and scope) devices reflects those attached.

   3. Modern versions of git-clone allow the --reference[-if-able] option, allowing a local cached replacement for some remote repository: preparing such a cache somewhere, e.g., in

      ${REPO_HOME}/example/data/cache

      can significantly improve efficiency wrt. repeated download of common repositories.

4. Either

   1. use targets in the top-level Makefile to drive a set of common tasks, e.g.,

      Command	Description
      make venv	build the Python virtual environment
      make doxygen	build the Doxygen-based documentation
      make spotless	remove everything built in ${REPO_HOME}/build

   2. execute the back-end infrastructure appliance directly.

Questions?

• read the wiki,
• raise an issue,
• raise a pull request,
• drop us an email.

Acknowledgements

This work has been supported in part

• by EPSRC via grant EP/R012288/1 (under the RISE programme), and
• by the AWS Cloud Credits for Research programme.