Results 1 -
4 of
4
Capability-based Financial Instruments
- In Proc. Financial Cryptography 2000, Anguila, BWI
, 2000
"... Every novel cooperative arrangement of mutually suspicious parties interacting electronically --- every smart contract --- effectively requires a new cryptographic protocol. However, if every new contract requires new cryptographic protocol design, our dreams of cryptographically enabled electronic ..."
Abstract
-
Cited by 27 (4 self)
- Add to MetaCart
Every novel cooperative arrangement of mutually suspicious parties interacting electronically --- every smart contract --- effectively requires a new cryptographic protocol. However, if every new contract requires new cryptographic protocol design, our dreams of cryptographically enabled electronic commerce would be unreachable. Cryptographic protocol design is too hard and expensive, given our unlimited need for new contracts.
Verifying Operating System Security
, 1997
"... A confined program is one which is unable to leak information to an unauthorized party or modify unauthorized resources. Confinement is an essential feature of any secure component-based system. This paper presents a proof of correctness of the EROS operating system architecture with respect to conf ..."
Abstract
-
Cited by 11 (6 self)
- Add to MetaCart
A confined program is one which is unable to leak information to an unauthorized party or modify unauthorized resources. Confinement is an essential feature of any secure component-based system. This paper presents a proof of correctness of the EROS operating system architecture with respect to confinement. We give a formal statement of the requirements, construct a model of the architecture's security policy and operational semantics, and show that the architecture enforces the confinement requirements if a small number of initial static checks on the confined subsystem are satisfied. The mechanism does not rely on the run-time values of user state or analysis of the programs' algorithm(s). Our verification methodology borrows heavily from techniques developed in the programming languages community. We view the operating system as a programming language whose operations are the kernel calls. This has the advantage that the security requirements of concern can be stated in for...
Design Evolution of the EROS Single-Level Store
- In Proceedings of the General Track: 2002 USENIX Annual Technical Conference
, 2002
"... File systems have (at least) two undesirable characteristics: both the addressing model and the consistency semantics differ from those of memory, leading to a change in programming model at the storage boundary. Main memory is a single flat space of pages with a simple durability (persistence) mo ..."
Abstract
-
Cited by 7 (0 self)
- Add to MetaCart
File systems have (at least) two undesirable characteristics: both the addressing model and the consistency semantics differ from those of memory, leading to a change in programming model at the storage boundary. Main memory is a single flat space of pages with a simple durability (persistence) model: all or nothing. File content durability is a complex function of implementation, caching, and timing. Memory is globally consistent. File systems offer no global consistency model. Following a crash recovery, individual files may be lost or damaged, or may be collectively inconsistent even though they are individually sound.
The Confused Deputy (or why capabilities might have been invented) Norm Hardy Senior
"... This is a nearly true story (inessential details have been changed). The events happened about eleven years ago at Tymshare, a company which provided commercial timesharing services. Be-fore this happened I had heard of capabilities and thought that they Were neat and tidy, but was not yet convinced ..."
Abstract
- Add to MetaCart
This is a nearly true story (inessential details have been changed). The events happened about eleven years ago at Tymshare, a company which provided commercial timesharing services. Be-fore this happened I had heard of capabilities and thought that they Were neat and tidy, but was not yet convinced that they were necessary. This occasion convinced me that they were necessary. Our operating system was much like Unix (aM of AT&T) in its protection structures. A compiler was installed in a directory called SYSX. A user would use the compiler by saying "RUN (SYSX)FORT", and could provide the name of a file to receive some optional debugging output. We had instrumented the compiler to collect statistics about language feature usage. The statistics file was called (SYSX)STAT, a name which was assembled into the compiler. To enable the compiler to write the (SYSX)STAT file, we marked the file holding the compiler { (9YSX)FORT} with homefiles license. The operating system allowed a program with such license to write files in its home directory, SYSX in our case. The billing information file (SYSX)BILL was also stored in SYSX. Some user came to know the name (9YSX)BILL and supplied it to the compiler as the name of the file to receive the debugging information. The compiler passed the name to the operating system in a request to open that file for

