Results 1 - 10
of
84
Building a high-performance, programmable secure coprocessor
- Computer Networks
, 1999
"... Abstract. Unsecure computational environments threaten many nancial cryptography implementations, and other sensitive computation. High-performance secure coprocessors can address these threats. However, using this technology for practical security solutions requires overcoming numerous technical an ..."
Abstract
-
Cited by 172 (33 self)
- Add to MetaCart
Abstract. Unsecure computational environments threaten many nancial cryptography implementations, and other sensitive computation. High-performance secure coprocessors can address these threats. However, using this technology for practical security solutions requires overcoming numerous technical and business obstacles. These obstacles motivate building a high-performance secure coprocessor that balances security with easy third-party programmability|but these obstacles also provide many design challenges. This paper discusses some of issues we faced when attempting to build such a device. 1
Automatic Generation of Program Specifications
- In ISSTA 2002, Proceedings of the 2002 International Symposium on Software Testing and Analysis
, 2002
"... Producing specifications by dynamic (runtime) analysis of program executions is potentially unsound, because the analyzed executions may not fully characterize all possible executions of the program. In practice, how accurate are the results of a dynamic analysis? This paper describes the results of ..."
Abstract
-
Cited by 56 (15 self)
- Add to MetaCart
Producing specifications by dynamic (runtime) analysis of program executions is potentially unsound, because the analyzed executions may not fully characterize all possible executions of the program. In practice, how accurate are the results of a dynamic analysis? This paper describes the results of an investigation into this question, determining how much specifications generalized from program runs must be changed in order to be verified by a static checker.
Static verification of dynamically detected program invariants: Integrating Daikon and ESC/Java
, 2001
"... This paper shows how to integrate two complementary techniques for manipulating program invariants: dynamic detection and static verification. Dynamic detection proposes likely invariants based on program executions, but the resulting properties are not guaranteed to be true over all possible execut ..."
Abstract
-
Cited by 51 (3 self)
- Add to MetaCart
This paper shows how to integrate two complementary techniques for manipulating program invariants: dynamic detection and static verification. Dynamic detection proposes likely invariants based on program executions, but the resulting properties are not guaranteed to be true over all possible executions. Static verification checks that properties are always true, but it can be difficult and tedious to select a goal and to annotate programs for input to a static checker. Combining these techniques overcomes the weaknesses of each: dynamically detected invariants can annotate a program or provide goals for static verification, and static veri cation can confirm properties proposed by a dynamic tool. We have
Structured Theory Development for a Mechanized Logic
- Journal of Automated Reasoning
, 1999
"... Experience has shown that large or multi-user interactive proof efforts can benefit significantly from structuring mechanisms, much like those available in many modern programming languages. Such a mechanism can allow some lemmas and definitions to be exported, and others not. In this paper we addre ..."
Abstract
-
Cited by 45 (15 self)
- Add to MetaCart
Experience has shown that large or multi-user interactive proof efforts can benefit significantly from structuring mechanisms, much like those available in many modern programming languages. Such a mechanism can allow some lemmas and definitions to be exported, and others not. In this paper we address two such structuring mechanisms for the ACL2 theorem prover: encapsulation and books. After presenting an introduction to ACL2, this paper justifies the implementation of ACL2's structuring mechanisms and, more generally, formulates and proves high-level correctness properties of ACL2. The issues in the present paper are relevant not only for ACL2 but also for other theorem-proving environments.
Lifted-FL: A Pragmatic Implementation of Combined Model Checking and Theorem Proving
, 1999
"... Abstract. Combining theorem proving and model checking o ers the tantalizing possibility of e ciently reasoning about large circuits at high levels of abstraction. We have constructed a system that seamlessly integrates symbolic trajectory evaluation based model checking with theorem proving in a hi ..."
Abstract
-
Cited by 31 (2 self)
- Add to MetaCart
Abstract. Combining theorem proving and model checking o ers the tantalizing possibility of e ciently reasoning about large circuits at high levels of abstraction. We have constructed a system that seamlessly integrates symbolic trajectory evaluation based model checking with theorem proving in a higher-order classical logic. The approach is made possible by using the same programming language ( ) as both the meta and object language of theorem proving. This is done by \lifting ",essentially deeply embedding in itself. The approach is a pragmatic solution that provides an e cient and extensible veri cation environment. Our approach is generally applicable to any dialect of the ML programming language and any model-checking algorithm that has practical inference rules for combining results. 1
Evaluating SFI for a CISC architecture
- In 15th USENIX Security Symposium (2006
"... Executing untrusted code while preserving security requires that the code be prevented from modifying memory or executing instructions except as explicitly allowed. Software-based fault isolation (SFI) or “sandboxing” enforces such a policy by rewriting the untrusted code at the instruction level. H ..."
Abstract
-
Cited by 27 (3 self)
- Add to MetaCart
Executing untrusted code while preserving security requires that the code be prevented from modifying memory or executing instructions except as explicitly allowed. Software-based fault isolation (SFI) or “sandboxing” enforces such a policy by rewriting the untrusted code at the instruction level. However, the original sandboxing technique of Wahbe et al. is applicable only to RISC architectures, and most other previous work is either insecure, or has been not described in enough detail to give confidence in its security properties. We present a new sandboxing technique that can be applied to a CISC architecture like the IA-32, and whose application can be checked at load-time to minimize the TCB. We describe an implementation which provides a robust security guarantee and has low runtime overheads (an average of 21 % on the SPECint2000 benchmarks). We evaluate the utility of the technique by applying it to untrusted decompression modules in an archive tool, and its safety by constructing a machine-checked proof that any program approved by the verification algorithm will respect the desired safety property. 1
Trusting Trusted Hardware: Towards a Formal Model for Programmable Secure Coprocessors
, 1998
"... Secure coprocessors provide a foundation for many exciting electronic commerce applications, as previous work [20, 21] has demonstrated. As our recent work [6, 13, 14] has explored, building a high-end secure coprocessor that can be easily programmed and deployed by a wide range of third parties can ..."
Abstract
-
Cited by 20 (4 self)
- Add to MetaCart
Secure coprocessors provide a foundation for many exciting electronic commerce applications, as previous work [20, 21] has demonstrated. As our recent work [6, 13, 14] has explored, building a high-end secure coprocessor that can be easily programmed and deployed by a wide range of third parties can be an important step toward realizing this promise. But this step requires trusting trusted hardware -- and achieving this trust can be difficult in the face of a problem and solution space that can be surprisingly complex and subtle. Formal methods provide one means to express, verify, and analyze such solutions (and would be required for such a solution to be certified at FIPS 140-1 Level 4). This paper discusses our current efforts to apply these principles to the architecture of our secure coprocessor. We present formal statements of the security goals our architecture needs to provide; we argue for correctness by enumerating the architectural properties from which these goals can be proven; we argue for conciseness by showing how eliminating properties causes the goals to fail; but we discuss how simpler versions of the architecture can satisfy weaker security goals. We view this work as the beginning of developing formal models to address the trust challenges arising from using trusted hardware for electronic commerce.
An open extensible tool environment for Event-B
- ICFEM 2006, LNCS
, 2006
"... Abstract. We consider modelling indispensable for the development of complex systems. Modelling must be carried out in a formal notation to reason and make meaningful conjectures about a model. But formal modelling of complex systems is a difficult task. Even when theorem provers improve further and ..."
Abstract
-
Cited by 20 (8 self)
- Add to MetaCart
Abstract. We consider modelling indispensable for the development of complex systems. Modelling must be carried out in a formal notation to reason and make meaningful conjectures about a model. But formal modelling of complex systems is a difficult task. Even when theorem provers improve further and get more powerful, modelling will remain difficult. The reason for this that modelling is an exploratory activity that requires ingenuity in order to arrive at a meaningful model. We are aware that automated theorem provers can discharge most of the onerous trivial proof obligations that appear when modelling systems. In this article we present a modelling tool that seamlessly integrates modelling and proving similar to what is offered today in modern integrated development environments for programming. The tool is extensible and configurable so that it can be adapted more easily to different application domains and development methods. 1

