Pedro Antonino

CR
3papers
2citations
Novelty53%
AI Score21

3 Papers

CRDec 1, 2021
Trusted And Confidential Program Analysis

Han Liu, Pedro Antonino, Zhiqiang Yang et al.

We develop the concept of Trusted and Confidential Program Analysis (TCPA) which enables program certification to be used where previously there was insufficient trust. Imagine a scenario where a producer may not be trusted to certify its own software (perhaps by a foreign regulator), and the producer is unwilling to release its sources and detailed design to any external body. We present a protocol that can, using trusted computing based on encrypted sources, create certification via which all can trust the delivered object code without revealing the unencrypted sources to any party. Furthermore, we describe a realization of TCPA with trusted execution environments (TEE) that enables general and efficient computation. We have implemented the TCPA protocol in a system called TCWasm for web assembly architectures. In our evaluation with 33 benchmark cases, TCWasm managed to finish the analysis with relatively slight overheads.

CRMay 12, 2021
Guardian: symbolic validation of orderliness in SGX enclaves

Pedro Antonino, Wojciech Aleksander Wołoszyn, A. W. Roscoe

Modern processors can offer hardware primitives that allow a process to run in isolation. These primitives implement a trusted execution environment (TEE) in which a program can run such that the integrity and confidentiality of its execution are guaranteed. Intel's Software Guard eXtensions (SGX) is an example of such primitives and its isolated processes are called \emph{enclaves}. These guarantees, however, can be easily thwarted if the enclave has not been properly designed. Its interface with the untrusted software stack is arguably the largest attack surface that adversaries can exploit; unintended interactions with untrusted code can expose the enclave to memory corruption attacks, for instance. In this paper, we propose a notion of an \emph{orderly} enclave which splits its behaviour into several execution phases each of which imposes a set of restrictions on accesses to untrusted memory, phase transitions and registers sanitisation. A violation to these restrictions indicates an undesired behaviour which could be harnessed to perpetrate attacks against the enclave. We also introduce \Analyser{}: a tool that uses symbolic execution to carry out the validation of an enclave against our notion of an orderly enclave; in this process, it also looks for some typical memory-corruption vulnerabilities. We discuss how our approach can prevent and flag enclave vulnerabilities that have been identified in the literature. Moreover, we have evaluated how our approach fares in the analysis of some practical enclaves. \Analyser{} was able to identify real vulnerabilities on these enclaves which have been acknowledged and fixed by their maintainers.

PLFeb 7, 2020
Formalising and verifying smart contracts with Solidifier: a bounded model checker for Solidity

Pedro Antonino, A. W. Roscoe

The exploitation of smart-contract vulnerabilities can have catastrophic consequences such as the loss of millions of pounds worth of crypto assets. Formal verification can be a useful tool in identifying vulnerabilities and proving that they have been fixed. In this paper, we present a formalisation of Solidity and the Ethereum blockchain using the Solid language and its blockchain; a Solid program is obtained by explicating/desugaring a Solidity program. We make some abstractions that over-approximate the way in which Solidity/Ethereum behave. Based on this formalisation, we create Solidifier: a bounded model checker for Solidity. It translates Solid into Boogie, an intermediate verification language, that is later verified using Corral, a bounded model checker for Boogie. Unlike much of the work in this area, we do not try to find specific behavioural/code patterns that might lead to vulnerabilities. Instead, we provide a tool to find errors/bad states, i.e. program states that do not conform with the intent of the developer. Such a bad state, be it a vulnerability or not, might be reached through the execution of specific known code patterns or through behaviours that have not been anticipated.