Skip to content
This repository has been archived by the owner on Apr 27, 2023. It is now read-only.

Latest commit

 

History

History
226 lines (187 loc) · 8.87 KB

README.md

File metadata and controls

226 lines (187 loc) · 8.87 KB

SCA3S: "side-channel analysis as a service"

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.

Overview

Forming a sub-field of more general implementation attacks, a side-channel attack on some cryptographic target demands (at least) two phases: a) acquisition of a data set, then b) (crypt)analysis of said data set, which aims to satisfy a goal such as key recovery. Particularly where the side-channel in question is analogue (e.g., power consumption) vs. digital (e.g., execution time) in nature, the acquisition phase can present some significant practical challenges. Examples include capital investment wrt. equipment, maintenance and operational experience, and logistics; even though low-cost platforms such as ChipWhisperer help to some extent, the concept of Total Cost of Ownership (TCO) means they can still impact on how applicable the approach is.

The SCA3S project is intended to act as a suite of tools that, in combination, help to address such challenges. The concept is simple: it aims to deliver a form of "side-channel analysis as a service", in a sense virtualising the resources and processes required by locating them in the cloud and offering remote access via high-level APIs. As a result, it has applications in a wide range of potential use-cases: examples include

  • a side-channel oriented form of Continuous Integration (CI), potentially allowing small development teams to improve the resilience of their cryptographic implementations,
  • shared use of bespoke or niche equipment, e.g., where some cryptographic design or standardisation process requires a forms of build-it, break-it, fix-it approach,
  • forms of CTF-like contest,
  • as a means of supporting scientific tenets such as open access and reproducibility wrt. research publications.

Organisation

├── bin                    - scripts (e.g., environment configuration)
├── build                  - working directory for build
├── doc                    - documentation
└── extern                 - external resources (e.g., submodules)
    ├── sca3s-backend        - submodule: scarv/sca3s-backend
    ├── sca3s-example        - submodule: scarv/sca3s-example
    ├── sca3s-harness        - submodule: scarv/sca3s-harness
    ├── sca3s-middleware     - submodule: scarv/sca3s-middleware
    ├── sca3s-cli            - submodule: scarv/sca3s-cli
    ├── texmf                - submodule: scarv/texmf
    └── wiki                 - submodule: scarv/sca3s.wiki

Originally this was a monorepo that housed all resources in one place, but, to make them easier to manage, it now acts as a container where each resource is housed in dedicated submodule. Specifically, these include:

  • scarv/sca3s-harness houses a framework for developing target implementations. The idea is that users will fork the repository, which then supports a a) uniform communication interface to, and b) build system for the target implementation then developed within it.

  • scarv/sca3s-example houses a forked instance of scarv/sca3s-harness, acting as an example for demonstration purposes: it includes, e.g., a basic AES-128 implementation.

  • scarv/sca3s-backend houses the software portion of the acquisition appliance; in combination with appropriate hardware, it allows generation data sets (e.g., power consumption traces) stemming from execution of a given target implementation.

  • scarv/sca3s-frontend houses the cloud-based, specifically AWS-based, infrastructure that provides all the user-facing functionality accessible via the web-based UI at sca3s.scarv.org.

    software portion of the acquisition appliance; in combination with appropriate hardware, it allows generation data sets (e.g., power consumption traces) stemming from execution of a given target implementation.

  • scarv/sca3s-middleware houses various shared components, e.g., allowing consistent interfaces between the frontend and backend.

  • scarv/sca3s-cli houses a CLI which allows interaction with the front-end infrastructure without using the web-based UI, e.g., as part of a scripted build process.

Quickstart (with more detail in the wiki)

Given the role as a container, you don't really use this repository in the same way as some others. Rather, various forms of documentation are the most natural route to getting started:

  • From a user-facing perspective, the harness repository is the central resource: almost everything else relates to either the front- and/or back-end infrastructure. The associated wiki contains a step-by-step workflow for using it, and so SCA3S more generally.

  • This repository houses some system-wide documentation:

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

      • a modern LaTeX distribution, such as TeX Live, including any required packages.
    2. Execute

      git clone https://github.com/scarv/sca3s.git ./sca3s
      cd ./sca3s
      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. Use targets in the top-level Makefile to drive a set of common tasks, e.g.,

      Command Description
      make build-doc build the LaTeX-based documentation
      make spotless remove everything built in ${REPO_HOME}/build
  • We maintain some Postman-based API documentation for the front-end infrastructure.

Questions?

Acknowledgements

This work has been supported in part