SpaceTEE: Secure and Tamper-Proof Computingin Space using CubeSats

Yan MichalevskyStanford University

yanm2@cs.stanford.edu

Yonatan WinetraubStanford University, SpaceILyonatanw1@stanford.edu

ABSTRACTSensitive computation o�en has to be performed in a trusted exe-cution environment (TEE), which, in turn, requires tamper-proofhardware. If the computational fabric can be tampered with, wemay no longer be able to trust the correctness of the computation.We study the idea of using computational platforms in space asa means to protect data from adversarial physical access. In thispaper, we propose SpaceTEE – a practical implementation of thisapproach using low-cost nano-satellites called CubeSats. We studythe constraints of such a platform, the cost of deployment, and dis-cuss possible applications under those constraints. As a case study,we design a hardware security module solution (called SpaceHSM)and describe how it can be used to implement a root-of-trust for acerti�cate authority (CA).

KEYWORDSTEE; tamper-proof hardware; tamper-proof computation; hardwaresecurity modules; certi�cate authority.

1 INTRODUCTIONExtremely sensitive computational operations, involving highlysecret data, require running on a computational platform that canbe trusted to maintain secrecy and computational integrity. Acommon requirement from such a platform is to be tamper-proof,meaning an adversary must not be able to change the way it works.�is property should be maintained across the stack, spanningso�ware and hardware. Unless complicated and computationallyheavy cryptographic techniques from veri�able computation areused (see for example [22, 40]), the so�ware have to eventuallytrust the hardware to perform operations correctly. In addition,we would like to ensure that the inner state of the computer is notvisible to an adversary.

Assuming secure so�ware implementation, and a functionallycorrect hardware design, we must prevent post-manufacturingadversarial modi�cations to the hardware, as well as physical accessto its components in order to read data from it.

Tamper-proof hardware is used in various products. One notableexample is Hardware Security Modules (HSM).

1.1 Hardware Security ModulesHSMs are used for generating and storing cryptographic keys, aswell as providing a restricted interface for performing well-de�nedcryptographic operations, such as message signing and veri�cation.

In Public-Key Infrastructures (PKI), HSMs are used by Certi�cateAuthorities (CA) to generate the signing keys, and to sign othercerti�cates. �us, the private key never leaves the HSM hardware,and is protected from so�ware a�acks on the CA infrastructure.

However, via physical access to the HSM it may potentially bepossible to obtain its secrets. HSM vendors such as Safenet and�ales incorporate many precautions and preventative measuresto secure their hardware and make it tamper-proof. One defensivemeasure is to protect them with sensors that identify an a�emptto open the HSM enclosure in order to access the board. �e FIPS140-2 US government standard [9] speci�es the requirements forcryptographic modules that protect sensitive (but unclassi�ed) in-formation for commercial uses.

FIPS 140-2 speci�es 4 levels of security. �e speci�cation forLevel 4 states

”Physical security mechanisms provide a completeenvelope of protection around the cryptographicmodule with the intent of detecting and respond-ing to all unauthorized a�empts at physical ac-cess.”

as well as”protects a cryptographic module against a secu-rity compromise due to environmental conditionsor �uctuations outside of the module’s normal op-erating ranges for voltage and temperature.”

�e National Institute of Standard and Technology (NIST), Crypto-graphic Module Validation Program (CMVP) periodically publishesa Validated FIPS 140-1 and FIPS 140-2 Cryptographic Modules list[19]. Out of 332, only 13 comply with Level 4 physical securityrequirements. We were unable to �nd public pricing and speci�ca-tions for Level 4 devices, however Level 3 devices in the list cost upto $50,000 and support 60 - 1200 RSA-2048 signatures per second.

Multiple works on side-channel a�acks show that extraction ofinternal state is possible even without opening the enclosure of acomputer [32], and even without direct contact with it [30, 31, 33],from a distance of up-to tens of meters.

In the following we propose using nano-satellites as a trusted,isolated environment for secure computation.

1.2 CubeSats�e CubeSat reference design was proposed in 1999 [34] as a cheapcommercial o�-the-shelf alternative to traditional expensive satel-lites. �e size of a CubeSat 1U is 10 × 10 × 10 cm, and it weightsless than 1.33 kg. As of June 24th 2017, 699 CubeSats have beenlaunched to orbit [13], with many active companies in the �eldgenerating a total revenue of $2B in 2014 [15]. CubeSats are mostlyused for academic research, however, many disruptive technologiesemerged around them recently. Increased production volume, andreduction in the cost of launching to orbit, have been driving thecost of launching a CubeSat down in the recent years. Furthermore,

arX

iv:1

710.

0143

0v2

[cs

.CR

] 8

Nov

201

7

Figure 1: LibreCube: an open-source CubeSat design.

many open-source CubeSat designs exist today (see �gure 1), open-ing the possibilities for innovative solutions that only a decade agowere not available.

1.3 Trusted Execution in SpaceCurrently, objects in the outer-space are hard to access physically1.However, they can communicate with one another, as well aswith terrestrial base-stations. Outer-space can therefore serve as aTrusted Execution Environment (TEE), providing strong isolationguarantees, that as of today are very unlikely to be violated evenby state-level adversaries. While anti-satellite weapons have beensuccessfully tested [1], they are currently able, at most, to destroya satellite, but not to capture it. In a security jargon, destructionconstitutes a denial-of-service (DoS) a�ack.

1.3.1 Physical Protection and Isolation in Space. It is very expen-sive to physically access a satellite launched into space. Althoughlaunching a satellite into space is inexpensive, a rendezvous withone in order to access its hardware is still a di�cult mission thatrequires great expertise and high-end equipment. However, as thecost of space exploration drops, this capability may becomemore ac-cessible. However, even if we will not be able to completely preventphysical access, we can know that such access was a�empted andrevoke that particular satellite as a reliable root-of-trust. �e NorthAmerican Aerospace Defense Command (NORAD [14]), since 1958,has been continuously mapping near-space to identify the course ofall objects. NORAD uses a network of ground-based radar systemsand telescopes to accurately determine and predict the trajectoryof objects of all sizes, as small as a baseball. NORAD’s data is freelyavailable online. A physical protection layer will involve dailymonitoring of the NORAD database (and others) to identify objectswhich approach our satellite.

1.3.2 Pre-launch Physical Protection. If the adversary gets accessto the satellite prior to launch, it could tamper with the spacecra�’shardware and so�ware. One way to make the solution tamper-evident2 is to coat the computer with kapton tape, and measurethe satellite’s inertial moment prior to launch. �e measurement

1Although we can imagine a di�erent situation in the future with advances in mobilityin space.2Meaning, it is easy to see that it has been tampered with (which is a common measurein traditional hardware security modules).

is compared to the observed rotation rate of the satellite once inorbit. It can be measured by tracking the antennas range-rate asthe satellite revolves[37], or via direct imaging of the satellite (de-pending on launch con�guration). By measuring the rotation ratechanges, we can estimate satellite’s actual moment of inertia [29]and verify it is identical to the expected one, measured prior tolaunch. Tampering with the coated hardware, or adding new one,inevitably changes the moment of inertia. Further analysis andsimulations are required to assess the constraints of this method.Although it is possible to reintroduce the original inertial moment,it is extremely di�cult to do within the time window of a launche�ort. In addition, during a launch, the vibrations induced on thesatellite from the rocket are likely to shake apart and destroy anycomponent that was not properly installed and tested for vibrations.

2 SPACE-HSMWe propose a design for a system that can serve as a certi�cateauthority (CA). It builds on traditional PKI, combined with the morerecent concept of Certi�cate Transparency [36]. We use certi�catetransparency logs to prevent a powerful a�acker, who gains accessto the communication channel with the CubeSat, from obtainingforged certi�cates, similar to the infamous DigiNotar incident [7].

2.1 System De�nitionOur system consists of the following entities (see Figure 2):

(1) A root-of-trust R provided by the SpaceHSM satellite. �eSpaceHSM handles certi�cate signing requests, and con-stantly updates a cryptographic accumulator – a one-waymembership function that enables proving inclusion inan append-only log, and, in our case, represents the com-plete history of signed requests. �e accumulator value isconstantly transmi�ed as the satellite orbits.

(2) A terrestrial ground station G that authenticates to thesatellite and delegates requests for certi�cate signing.

(3) A public append-only certi�cate log L (similar to Certi�-cate Transparency [36]) that includes the history of allsigned certi�cates. We expect to have a match betweenthe accumulator published by the SpaceHSM and the onecomputed over the certi�cate log.

(4) A veri�erV that is presented with a certi�cate, and checkswhether it is valid.

2.2 �reat model (without DoS protection)As a �rst step, we state a simpli�ed threat model that demonstratessecurity but does not consider denial-of-service a�acks in the pres-ence of adversaries that can communicate with the satellite.

First and foremost, we assume that our space-based hardwareis tamper-proof and the access to it is restricted to a well-de�nedsatellite communication channel3. No physical access to the satel-lite is possible, as we argue in section 1.3.1. We consider a powerfuladversary that is occasionally able to gain access to all terrestrialinfrastructure, and circumvent all physical security solutions such

3Satellites o�en support a command that dumps and transmits all so�ware and datato ground station. We assume no such command is supported in ours.

2

SpaceHSM (R)

GroundStation(GS)

CertificateSigningRequest

SignedCertificate

Accumulator

PublicCertificateLog(L)

Figure 2: �e SpaceHSM System.

as locally installed traditional HSM machines, etc. It can temporar-ily obtain wide control of servers connected to the network. �ea�acker gains temporary access to the communication channelwith the SpaceHSM satellite, which enables her to issue requests tosign forged certi�cates.

Moreover, we assume that the a�acker (and everyone else) hasfull visibility of the so�ware running on the SpaceHSM, and fullread-access to code and data prior to the satellite launch. Finally, weassume that spoo�ng transmission from a particular satellite overa considerable period of time, and at many geographic locations(ground stations) is hard4.

2.3 Protocol descriptionBootstrap. Once launched, the SpaceHSM satellite generates aprivate/public key-pair, and starts broadcasting the public key. Onceenough ground stations agree on the transmi�ed public key, weconsider the system online. Consensus between ground stations canbe reached via Byzantine fault-tolerant protocols (see for instance[26]), or by relying on a public-key infrastructure (PKI). Security ofthis stage follows from our assumption regarding the di�culty ofspoo�ng communication from the satellite over time and location.Boosting trust. An extension of this proposal considers multipleSpaceHSM satellites on di�erent orbits. When two satellites are inline-of-sight of one another, they can exchange a�estations of theirrespective public keys. �en, each one of them can broadcast thesigned a�estation, increasing the trust in the public key identity.Certi�cate Request. A request to sign a certi�cate is transmi�edto the SpaceHSM, encrypted under its public key for privacy. �eSpaceHSM generates a signed certi�cate, and updates an accumu-lator representing the history of all signature requests. We usea constant-size accumulator, which suits well the present band-width and storage constraints. A Merkle hash-tree [38], or an RSAaccumulator [23], can serve the purpose.

It is important that the certi�cate is actually signed, in addi-tion to updating the accumulator since it guarantees to anyone4Essentially it would require a satellite with a similar orbit. However, NORAD wouldalert about any such existing satellite.

presented with the signed certi�cate, that the SpaceHSM updatedits accumulator. �at, in turn, guarantees that any inconsistencywould have been noticed by monitoring parties.Certi�cate Veri�cation. Anyone presented with the signed cer-ti�cate can verify its authenticity using the public key broadcast atthe bootstrap stage.Certi�cate Log Update. We expect every signed certi�cate tobe submi�ed to the publicly accessible certi�cate log. When logserver L receives a new signed certi�cate, it veri�es the signatureusing R’s public key, and appends it to the log. Anyone can thencompute an accumulator over the log and compare it to the onebeing broadcast by the SpaceHSM R. We call such parties monitors.

2.3.1 Security. Security and trust stem from correspondencebetween the accumulator value transmi�ed by the SpaceHSM to thevalue that is can be computed over the publicly readable terrestrialcerti�cate log. An adversary may be able to take over a groundstation and request to sign a forged certi�cate that is not subse-quently submi�ed to the public terrestrial certi�cates log. However,in that case, the SpaceHSM’s accumulator is updated to a new value,resulting in a mismatch that would be readily noticed by the logmonitors.

2.4 �reat model (with DoS)�is extended threat model considers Denial-of-Service (DoS) at-tacks on the system. �e protocol in section 2.3 enables anyonewho can communicate with the satellite to request the SpaceHSMto sign a certi�cate. Failure to submit the signed certi�cate to thelog results in an inconsistency between the publicly computeableaccumulator and the one being broadcast by the SpaceHSM. Such amismatch results in a service disruption. Without appending theadversary’s certi�cate to the log we cannot synchronize it with thestate of the SpaceHSM. We therefore need a reset procedure for theSpaceHSM.

We assume that the ground station and the satellite establisha secure communication channel, using a shared secret key. �eadversary is occasionally able to steal this shared key, which resultsin a disruption to the service. In this threat model, the adversaryhas no access to the SpaceHSM prior to the launch. Finally weassume the existence of a secure o�ine storage on earth.

2.5 Protection against adversarial requests�is measure addresses the case of an adversary that a�empts tocause denial of service by frequently issuing certi�cate signingrequests and transmi�ing them to the satellite. We stress that evenif such an incident occurs, it has no e�ect on the trustworthinessof the certi�cates signed by the SpaceHSM. �is procedure is onlyfor the sake of preventing DoS a�acks by parties that are normallynot authorized to send certi�cate signing requests directly.

One straightforward solution is to have the SpaceHSM broadcastevery signed certi�cate, such that it is visible to all certi�cate logservers, instead of returning it via the private channel accessibleonly to the ground-station. In the following, we suggest anotheralternative.

We propose a reset procedure when a mismatch between thesatellite broadcast and the active log is encountered. A random seed

3

Component Model Name NotesStructure 1U CubeSatOBC Cube Computer [6] ARM Cortex-M3

Power system CS 1U Bundle A 10 Whr ba�erySolar panels Azurspace panels [5] On all 6 sidesTransceiver ISIS VHF/UHF [17] Full-duplexAntennas ISIS dipole

Table 1: Bill of materials.

is generated prior to launch and a cryptographic pseudo-randomnumber generator (PRG) is seeded. �e state of the PRG is pro-grammed intro the SpaceHSM, and is used to derive the �rst sharedsymmetric key. �is state is also stored in a secure and inaccessibleo�ine terrestrial storage. �e o�ine storage prevents any onlinea�acker from accessing the seed. When an inconsistency is noticed,we fetch the stored PRG state and use it to generate the next key. Ifthe SpaceHSM fails to decrypt the channel using the i-th (current)key, it generates the i + 1 key and a�empts decryption, in order toautomatically identify the state transition. �e previous certi�catelog is no longer extended with new certi�cate and its state is frozen.Instead, L initializes a new log that is extended with new certi�-cates signed a�er the key transition. �e old log is still accessible,and enables verifying inclusion of certi�cates signed prior to thekey transition.

3 IMPLEMENTATION3.1 Space Segment HardwareWe propose to use commercial o�-the-shelf CubeSat parts thatwere tested in space. �e satellite is launched to a Sun SynchronousOrbit (SSO), which is a common design choice for CubeSats. Table 1provides a bill of materials, and Figure 3 provides a candidate CADdesign.

�e main on-board computer (OBC) is a Cube Computer [6],consisting of a 32-bit ARM Cortex-M3 with 4MB Flash memoryfor code storage, and 2 × 1MB SRAM memory for data storage. Inour design, we connect it to an external 48MHz clock. �e CubeComputer underwent radiation testing and was quali�ed for spacemissions. Its error detection and correction (EDAC) hardware isable to detect and correct Single Event Upset (SEU) and Single EventLatch (SEL). By referring to published pricings of the componentsin Table 1, we estimate that the marginal cost for building andlaunching a SpaceHSM satellite to polar low Earth orbit is on theorder of 170,000 USD, or about 95,000 USD per HSM, if two arebundled together into one satellite . It is higher, but comparable toprices of other HSMs on the market that provide FIPS 140-2 Level4 physical security. As we can see in Figure 3, we have enoughspace to accommodate 2 independent (except for power supply)HSMs, each with its own antenna, transceiver and computer in oneCubeSat.

3.2 Power BudgetIn a typical SSO orbit, satellites have 45 minutes of daylight and 45minutes of night-time, where the satellite is in the Earth’s shadow(eclipse).

VHF and UHF Antennas

Electrical Power System

On Board Computer

Battery Transducer Payload Space

Figure 3: Proposed satellite CAD model (solar panels andsecondary structure are not shown).

Daylight Input Power Generation. �e satellite will be poweredusing 6 high-end solar panels with 30% e�ciency [5]. �e totalaverage power input is computed (similarly to [21]) to be 3.82[W ].Daytime Power Consumption. �ree components contribute tothe daytime power consumption: the on-board computer, with anaverage of 0.2[W ] [6]; the transceiver, which consumes 1.7[W ] dur-ing transmission and 0.2[W ] while receiving [17], and given a dutycycle of 30% at transmission, results in average power consumptionof 0.65[W ]; and �nally ba�ery recharging a�er night operation,which consumes 0.85[W ].

�e total consumption by a single SpaceHSM is 1.7[W ], whichis 44% of the generated power, meaning the satellite has enoughpower to sustain two SpaceHSMs.Night-time Power Consumption. At night, the satellite drawspower from a ba�ery to operate both the transceiver and the on-board computer with the same power consumption as in daylight:0.85[W ]. In 45 min of nigh�ime, the satellite consumes 0.64[W ·hr ]drawn from the 10[W · hr ] ba�ery. A satellite’s depth of dischargeis very low (less then 10%), which guarantees long ba�ery life tosupport a satellite in orbit for several years [18].

3.3 Link Budget and Bit RatesWe consider a typical certi�cate signing request size of 2.5 KBytestransmi�ed to the satellite, and a 256 byte long RSA-2048 signatureand a 32 byte long accumulator using a SHA-256 hash, broadcastin response. We assume a standard CubeSat datalink using theAX.25 protocol [2]. An AX.25 frame adds a maximum overhead of35 bytes, that wraps 256 bytes of data (Info �eld) [3]. 5 bytes ofthe Info �eld are used as a message header [4]. We are le� with251 bytes per packet available for custom data. �erefore, for eachcerti�cate request, the SpaceHSM receives 11 AX.25 packets (24,000bit) and sends one AX.25 packet (600 bit).

We do not elaborate on the link budget since our transducer wassuccessfully tested in SSO, with a standard armature radio groundstation. According to [17], we expect an uplink of 1200bps - enoughfor one certi�cate request every 20 seconds. �e downlink rate of2400 bps at a 30% duty cycle enables sending a reply every second.Due to orbital mechanics, we can communicate with the satellitefor 10min every 90min using Svalbard ground station.

4

�ese rates can be improved in the future by a factor of 1,000 byusing an S-Band transceiver capable of uplink rates of 2 Mbps [8].However, using it, requires a monopole / dipole S-Band antennaand a suitable ground station. �ey can be custom-ordered, but arenot yet widely available commercially for CubeSats. We believethat this technology will be widely used within a few years, whichwould enable handling 50 certi�cate signing requests per second.

3.4 So�wareSpaceHSM requires crypto algorithms, including symmetric en-cryption (AES-128 and AES-256) and, depending on the chosenPKI algorithms, RSA-2048 and RSA-4096 signatures, ECDSA sig-natures, and Curve25519. Due to limited resources we use a smallcryptographic library. To give a few examples: TweetNaCl [24] isa tiny cryptographic library with compiled binary size of 11 KB,support around 40 RSA-2048 decryptions per second on an ArmCortex M3. mbedTLS [12], while larger, is very functional andstill �ts within our RAM budget. Its compiled binary takes 125 KB.Another alternative is the RTOS ready SharkSSL library, that wasspeci�cally benchmarked on ARM Cortex M3 [16]. Its binary sizeis approximately 15 KB. Finally, WolfSSL [20] is a small commercialopen-source library that supports TLS 1.3, ChaCha20, Curve25519in addition to the standard crypto algorithms.

3.5 Fault protectionIt is important to protect cryptographic protocols from random (orinjected) faults [25]. While random faults can potentially be causedby radiation in space, the tests mentioned in section 3.1 show thatall bit-�ips (SEU) are identi�ed by the EDAC, and are corrected.E�ectively, it implies that random faults are very unlikely to occurduring the lifespan of the SpaceHSM. Faults can potentially beinjected by heating the satellite using a laser beam. Nevertheless, weprotect against fault-a�acks on signature algorithms by verifyingthe computed signature.

4 ADDITIONAL APPLICATIONSOur proposal has signi�cant advantages over terrestrial comput-ers in the ability to isolate, and to protect against physical access.However, its drawback is the relatively low communication band-width, as well as the relatively limited processing power, due tousage of micro-processors. Notably, the link is not symmetric –the bo�leneck is the uplink to the satellite, which precludes up-loading large amounts of data to the satellite for computing in anisolated environment. In classic satellite applications, the downlinkrate is usually the bo�leneck, rather than the uplink. �ereforemost existing products are tailored to have high downlink at theexpense of a high uplink rate. Further research is needed to be�erunderstand how uplink rate can be improved at the expense of alower downlink rate. Additional applications and implementationsof secure and tamper proof computing in space may include:

Trusted Public Parameter Generator. Cryptographic schemeso�en rely on a trusted setup, that occurs once, and outputs commonpublic parameters. Any secret values generated during the setupmust be “forgo�en” a�er, and remain inaccessible. �e SpaceTEE

platform, with its support for random number generation and cryp-tographic functionality, is a perfectly suitable party for executingsuch algorithms.

Trusted Party for Cryptographic Protocols. Many crypto-graphic protocols (electronic voting, privacy-preserving aggrega-tion) require a trusted party, that performs a certain computationwithout revealing the internal state, and that cannot be corruptedby an adversary. Our CubeSat, loaded with suitable so�ware canpotentially be such a party. Currently, it suits only moderate work-loads, which can however be useful for certain protocols. A sim-ple e-voting protocol involves submi�ing inputs encrypted underan additively-homomorphic encryption scheme. �e inputs are”summed-up”, resulting in an encryption of the aggregate value. Atrusted party then decrypts the ciphertext and outputs the result.Such a trusted party can be implemented using SpaceTEE.

Trusted Mining. �e SpaceTEE can serve as a trusted miner forcryptocurrencies similar to Bitcoin and Ethereum. A major concernin cryptocurrencies, is that miners with a large percentage of thehashing power can adopt a non-standard mining strategy in ana�empt to pro�t beyond the standard transaction fees [27, 28, 35].For instance, they can ignore the most recent block, etc. Executionin a trusted environment can guarantee strict adherence to a certainmining strategy, decided prior to launch.

Trusted Timestamping enables securely keeping track of cre-ation and modi�cation of documents and media, and can be use-ful for instance for copyright purposes. A client can request theSpaceHSM to sign a message containing a hash of the documentand a timestamp at the time of signing, and later reveal the originaldocument, i.e. the hash function preimage, claiming ownership.

5 RELATEDWORK�e project on �rstspacebank.com [10] sets to provide a secureand decentralized satellite banking platform. �e website, unfor-tunately, provides no further details beyond this short statement.Laurie’s technical report on Certi�cate Transparency [36] providesan excellent explanation of the motivation behind it and its design.�ere are various proposals for implementation of cryptographicaccumulators, starting with the original paper by Benaloh and deMare [23]. Tremel [39] provides a review of various accumulators,and compares the performance of their real-world implementa-tions. �e following survey, [11], demonstrates new and emergingapplications for CubeSats.

6 CONCLUSIONIn this work, we present a novel idea of using computational plat-forms in space as a means to protect data from adversarial physicalaccess. We demonstrated one application of such tamper-proofplatform by showing how Hardware Security Modules for a PKIecosystem can be implemented using an inexpensive CubeSat thatcan be built using readily available commercial o�-the-shelf hard-ware. A signi�cant impediment to using space-based tamper-proofcomputation today, is the limited communication bandwidth to andfrom the satellite, as well as the relatively low processing power.However, in the near future signi�cant advancements can be donein the �eld.

5

ACKNOWLEDGEMENTSWe would like to thank Elad Sagi and Avi Barliya for reviewingthe satellite concept and design, and Henry Corrigan-Gibbs for re-viewing and commenting on the security aspects of the system. Wethank the anonymous reviewers for providing valuable commentson the paper. Finally, we thank LibreCube for licensing the artisticmaterials on their website under a Creative Commons license.

REFERENCES[1] 2007 Chinese anti-satellite missile test. h�ps://en.wikipedia.org/wiki/2007

Chinese anti-satellite missile test.[2] AX.25 protocol defenition. h�ps://www.tapr.org/pdf/AX25.2.2.pdf.[3] AX.25 Telemetry and Telecommand Transfer Frames Format. h�ps://www.qb50.

eu/index.php/tech-docs/category/16-archive?download=19:scs-docs.[4] AX.25 Telemetry and Telecommand Transfer Frames Format. h�ps://www.qb50.

eu/index.php/tech-docs/category/16-archive?download=67:scs-docs.[5] Azur space triple junction gaas solar cell datasheet. h�p://www.azurspace.com/

images/0003429-01-01 DB 3G30C-Advanced.pdf.[6] Cube computer datasheet. h�ps://www.cubesatshop.com/product/

cube-computer/.[7] DigiNotar. h�ps://en.wikipedia.org/wiki/DigiNotar.[8] ENUROSat user manual. h�ps://www.endurosat.com/modules-datasheets/

COMM User Manual Rev1.6.pdf?x65766.[9] FIPS 140-2, Security Requirements for Cryptographic Modules. h�p://nvlpubs.

nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf.[10] �e �rst space bank. h�p://�rstspacebank.com/.[11] Market innovation driving cubesats into the main-

stream. h�p://interactive.satellitetoday.com/via/march-2017/market-innovation-driving-cubesats-into-the-mainstream/.

[12] mbedTLS cryptographic library. h�ps://tls.mbed.org.[13] Nanosatellite database. h�p://www.nanosats.eu/.[14] North American Aerospace Defens Command (NORAD). h�p://www.norad.mil/.[15] Satellite Market Analysis by SIA 2014. h�p://www.sia.org/wp-content/uploads/

2015/06/Mktg15-SSIR-2015-FINAL-Compressed.pdf.[16] SharkSSL Embedded SSL/TLS Client and Server. h�ps://realtimelogic.com/

products/sharkssl/.[17] SIS VHF/UHF datasheet. h�ps://www.cubesatshop.com/product/

isis-vhf-downlink-uhf-uplink-full-duplex-transceiver/.[18] Space ba�ery life span analysis. h�p://digitalcommons.usu.edu/cgi/viewcontent.

cgi?article=1499&context=smallsat.[19] Validated FIPS 140-1 and FIPS 140-2 Cryptographic Modules, accessed July 20th,

2017. h�p://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm.[20] WolfSSL: Embedded SSL library. h�ps://www.wolfssl.com.[21] S. S. Arnold, R. Nuzzaci, and A. Gordon-Ross. Energy budgeting for cubesats

with an integrated fpga. In Aerospace Conference, 2012 IEEE, pages 1–14. IEEE,2012.

[22] E. Ben-Sasson, A. Chiesa, D. Genkin, E. Tromer, and M. Virza. Snarks for c:Verifying program executions succinctly and in zero knowledge. CryptologyePrint Archive, Report 2013/507, 2013. h�p://eprint.iacr.org/2013/507.

[23] J. Benaloh and M. D. Mare. One-way accumulators: A decentralized alternativeto digital signatures. Advances in Cryptology�EUROCRYPT’93, 765:274–285, 1994.

[24] D. J. Bernstein, B. Van Gastel, W. Janssen, T. Lange, P. Schwabe, and S. Smet-sers. Tweetnacl: A crypto library in 100 tweets. In International Conference onCryptology and Information Security in Latin America, pages 64–83. Springer,2014.

[25] D. Boneh, R. DeMillo, and R. Lipton. On the importance of checking crypto-graphic protocols for faults. In Advances in Cryptology - EUROCRYPT’97, pages37–51. Springer, 1997.

[26] M. Castro, B. Liskov, et al. Practical byzantine fault tolerance. In OSDI, volume 99,pages 173–186, 1999.

[27] N. T. Courtois and L. Bahack. On subversive miner strategies and block with-holding a�ack in bitcoin digital currency. arXiv preprint arXiv:1402.1718, 2014.

[28] I. Eyal and E. G. Sirer. Majority is not enough: Bitcoin mining is vulnerable.In International conference on �nancial cryptography and data security, pages436–454. Springer, 2014.

[29] P. Ferguson. On-orbit spacecra� inertia and rate sensor scale factor estimationfor microsatellites. 2008.

[30] D. Genkin, L. Pachmanov, I. Pipman, and E. Tromer. Stealing keys from pcsusing a radio: Cheap electromagnetic a�acks on windowed exponentiation. InCryptographic Hardware and Embedded Systems–CHES 2015: 17th InternationalWorkshop, Saint-Malo, France, September 13-16, 2015, Proceedings, volume 9293,page 207. Springer, 2015.

[31] D. Genkin, L. Pachmanov, I. Pipman, E. Tromer, and Y. Yarom. ECDSA keyextraction from mobile devices via nonintrusive physical side channels. InProceedings of the 2016 ACM SIGSACConference on Computer and CommunicationsSecurity, pages 1626–1638. ACM, 2016.

[32] D. Genkin, I. Pipman, and E. Tromer. Get your hands o� my laptop: Physicalside-channel key-extraction a�acks on pcs. In Cryptographic Hardware andEmbedded Systems–CHES 2014, pages 242–260. Springer Berlin Heidelberg, 2014.

[33] D. Genkin, A. Shamir, and E. Tromer. RSA Key Extraction via Low-BandwidthAcoustic Cryptanalysis. Cryptology ePrint Archive, Report 2013/857, 2013.h�p://eprint.iacr.org/2013/857.

[34] H. Helvajian and S.W. Janson. Small satellites: past, present, and future. AerospacePress, 2008.

[35] J. A. Kroll, I. C. Davey, and E. W. Felten. �e economics of bitcoin mining, orbitcoin in the presence of adversaries. In Proceedings of WEIS, volume 2013, 2013.

[36] B. Laurie. Certi�cate Transparency. �eue, 12(8):10–19, 2014.[37] J. W. Marini. A test of the e�ect of satellite spin on two-way doppler range-rate

measurements. IEEE Transactions on Aerospace and Electronic Systems, (3):269–272, 1972.

[38] R. C. Merkle. A certi�ed digital signature. In Conference on the �eory andApplication of Cryptology, pages 218–238. Springer, 1989.

[39] E. Tremel. Real-world performance of cryptographic accumulators. Undergradu-ate Honors �esis, Brown University, 2013.

[40] R. S. Wahby, M. Howald, S. Garg, abhi shelat, and M. Wal�sh. Veri�able asics.Cryptology ePrint Archive, Report 2015/1243, 2015. h�p://eprint.iacr.org/2015/1243.

6