├── logo.png └── README.md /logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/PLSysSec/ct-wasm/HEAD/logo.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ------------ 4 | 5 | # CT-Wasm: Type-driven Secure Cryptography for the Web Ecosystem 6 | 7 | This repository contains all the code and data necessary for building CT-Wasm 8 | and reproducing the results presented in [our paper](https://arxiv.org/abs/1808.01348). 9 | 10 | ## Abstract 11 | 12 | A significant amount of both client and server-side cryptography is implemented 13 | in JavaScript. Despite widespread concerns about its security, no other 14 | language has been able to match the convenience that comes from its ubiquitous 15 | support on the "web ecosystem" - the wide variety of technologies that 16 | collectively underpin the modern World Wide Web. With the new introduction of 17 | the WebAssembly bytecode language (Wasm) into the web ecosystem, we have a 18 | unique opportunity to advance a principled alternative to existing JavaScript 19 | cryptography use cases which does not compromise this convenience. 20 | 21 | Constant-Time WebAssembly (CT-Wasm) is a type-driven strict extension 22 | to WebAssembly which facilitates the verifiably secure implementation of 23 | cryptographic algorithms. CT-Wasm's type system ensures that code written in 24 | CT-Wasm is both information flow secure and resistant to timing side channel 25 | attacks; like base Wasm, these guarantees are verifiable in linear time. 26 | Building on an existing Wasm mechanization, we mechanize the full CT-Wasm 27 | specification, prove soundness of the extended type system, implement a 28 | verified type checker, and give several proofs of the language's security 29 | properties. Our security proofs use a novel representation of abstract 30 | information leakage based on quotient types. 31 | 32 | We provide two implementations of CT-Wasm: an OCaml reference interpreter and a 33 | native implementation for Node.js and Chromium that extends Google's V8 engine. 34 | We also implement a CT-Wasm to Wasm rewrite tool that allows developers to reap 35 | the benefits of CT-Wasm's type system today, while developing cryptographic 36 | algorithms for base Wasm environments. We evaluate the language, our 37 | implementations, and supporting tools by porting several cryptographic 38 | primitives---Salsa20, SHA-256, and TEA - and the full TweetNaCl library. We 39 | find that CT-Wasm is fast, expressive, and generates code that we 40 | experimentally measure to be constant-time. 41 | 42 | ## Reproducing Evaluation Results 43 | We provide automated scripts for reproducing the evaluation results in the 44 | [`ct-wasm-ports`](https://github.com/PLSysSec/ct-wasm-ports) repository. This repository contains a collection of programs 45 | ported to CT-Wasm. 46 | 47 | First, install prequisites: 48 | 49 | ### Build Prequisites 50 | 51 | - git 52 | - node 53 | - python3 + numpy 54 | - GNU coreutils 55 | 56 | 57 | #### Transitive Dependencies 58 | 59 | (Copied from their respective projects) 60 | 61 | **Node.js w/ CT-WASM** 62 | 63 | - gcc and g++ 4.9.4 or newer, or 64 | - clang and clang++ 3.4.2 or newer (macOS: latest Xcode Command Line Tools) 65 | - Python 2.6 or 2.7 66 | - GNU Make 3.81 or newer 67 | 68 | **Reference Interpreter** 69 | 70 | - Ocaml >= 4.05 71 | - ocamlbuild 72 | - Ocaml num library (for extracted verified compiler). OPAM users can install the num library with: `opam install num` 73 | 74 | ### Building Evalutation Suite 75 | 76 | Simply clone the repository and enter the `eval` directory: 77 | 78 | ```bash 79 | git clone https://github.com/PLSysSec/ct-wasm-ports 80 | cd ct-wasm-ports/eval 81 | ``` 82 | 83 | *All subsequent make commands below should be performed within this directory* 84 | 85 | #### Validation Performance 86 | We measure the performance of our validator as implemented in the Node.js runtime (`ct_node`) against a baseline (but 87 | instrumented) Node.js. The following command will build `ct_node` and `node` (as necessary), and measure the time to validate a series of CT-Wasm programs. 88 | 89 | ```bash 90 | make validation 91 | ``` 92 | 93 | The output can be found in `results/validation_timing.csv`, measured in milliseconds. 94 | By default, we validation each CT-Wasm program, 10,000 times. If you wish to tweak this number, simply set the `VAL_TRIALS` environment variable like so: 95 | 96 | ``` 97 | VAL_TRIALS=3000 make validation 98 | ``` 99 | 100 | If you've already generated the `csv` you will need to move or delete it for 101 | the `make` command to run. 102 | 103 | #### Runtime Performance 104 | We measure performance of our `ct_node` implementation of CT-Wasm against a 105 | baseline `node`. The following command will build both and execute various 106 | algorithms, measuring each 10,000 times: 107 | 108 | ``` 109 | make runtimes 110 | ``` 111 | 112 | Results can be found in `results/crypto_benchmarks.csv` measured in cycles. 113 | Salsa20 and SHA-256 measure the cycles to encrypt 4KB, while TEA measures the 114 | cycles to encrypt 8 bytes. 115 | 116 | #### Statistical Timing for Security with dudect 117 | We empirically measure the timing characteristics using a modified version of 118 | [dudect](https://github.com/oreparaz/dudect), which works by collecting samples for a fixed amount of time. By 119 | default, that time is 10 seconds. The following command will build our [modified dudect](https://github.com/PLSysSec/dudect) and our extended Node.js (`ct_node`) if not already built, and will collect the data into `results/dudect`: 120 | 121 | ```bash 122 | DUDE_TIMEOUT=10 make dudect 123 | ``` 124 | 125 | where `DUDE_TIMEOUT` is the sampling time in seconds. The `make` command will 126 | not do anything if you have results already present on disk. 127 | 128 | #### Bytecode Size Overhead 129 | The following command will translate a variety of programs written in CT-Wasm 130 | to bytecode and measure their size: 131 | 132 | ``` 133 | make bytecode_sizes 134 | ``` 135 | 136 | The output can be found in `results/file_sizes.csv`. 137 | 138 | #### Node TweetNacl Benchmarks 139 | [TweetNacl](https://github.com/TorstenStueber/TweetNacl-WebAssembly) ships with a series of benchmarks that measure the performance of its various APIs. These benchmarks take a while to execute. We run their benchmarks a number of times (10 bellow), taking the median value, like so: 140 | 141 | ``` 142 | TWEET_TRIALS=10 make tweetnacl 143 | ``` 144 | 145 | This will store the results in `results/node_tweetnacl.csv`. 146 | 147 | ### Mechanized Proofs 148 | 149 | Our mechanization effort and instructions for running Isabelle are described in the [`ct-wasm-proofs`](https://github.com/PLSysSec/ct-wasm-proofs) repository. 150 | 151 | ## CT-Wasm Implementations 152 | 153 | Though the evaluation scripts above pull the Node.js implementation of CT-Wasm, we include references to all our implementations for completeness: 154 | 155 | - [Reference interpreter](https://github.com/PLSysSec/ct-wasm-spec) 156 | - [Node.js implementation](https://github.com/PLSysSec/ct-wasm-node) 157 | - [Chromium implementation](https://github.com/PLSysSec/ct-wasm-chromium) 158 | 159 | Our implementations fork existing projects, so unless otherwise highlighted, 160 | you should follow the standard build and installation process. 161 | 162 | For convenience, we provide [binary 163 | releases](https://github.com/PLSysSec/ct-wasm-spec/releases/artifact) for macOS 164 | and 64 bit Linux. Other platforms should work, but are untested and will need 165 | to build from source. 166 | 167 | These releases contain 3 binaries: 168 | 169 | - `ct_node`: a version of Node.js that natively supports the use of CT-Wasm. 170 | - `ct2wasm`: tool for removing secrecy labels. Since this is built in the interpreter the `-strip` flag is required. 171 | - `ct_wasm_spec`: a build of the spec interpreter. The interpreter supports simple secrecy inference via the `-r` flag. 172 | 173 | 174 | ### Source Distribution 175 | 176 | CT-Wasm efforts are split across a few different repositories. The evaluation step pulls from these directly. We include the links for complteness. 177 | 178 | - [`ct-wasm-node`](https://github.com/PLSysSec/ct-wasm-node): An implementation of CT-Wasm Node.js/V8. 179 | - [`ct-wasm-spec`](https://github.com/PLSysSec/ct-wasm-spec): Reference OCaml implementation CT-Wasm with accompanying label stripping and label inference tools. 180 | - [`ct-wasm-ports`](https://github.com/PLSysSec/ct-wasm-ports): Crypto algorithm implementations and evaluation scripts. 181 | - [`tweetnacl-ctwasm`](https://github.com/PLSysSec/tweetnacl-ctwasm): A port of the TweetNacl library with secrecy annotations. 182 | - [`ct-wasm-proofs`](https://github.com/PLSysSec/ct-wasm-proofs): Mechanizations (in Isabelle) of all proofs in the paper. 183 | - [`dudect`](https://github.com/PLSysSec/dudect): A fork of dudect that's compatible with our instrumented Node.js. 184 | - [`ct-wasm-chromium`](https://github.com/PLSysSec/ct-wasm-chromium): V8 patches (same as Node.js) for Chromium. 185 | --------------------------------------------------------------------------------