And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA [email protected] vishwas.

13
and SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA [email protected] http://www.tcs.tifr.res.in/~vishwas

Transcript of And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA [email protected] vishwas.

Page 1: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

and SPKI

Vishwas PatilSTCS, TIFR, Mumbai, INDIA

[email protected]://www.tcs.tifr.res.in/~vishwas

Page 2: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

What is E?• E is a simple, secure, distributed, pure-object, persistent

programming language. • E blends the lambda calculus, capability security, and

modern cryptography.

• It has two parts: ELib and E Language• ELib provides the stuff that goes on between objects. • The E Language can be used to express what happens within an object.

• E provides cryptographic capabilities as an abstraction allowing economy of engineering effort in creating smart contracts.

Page 3: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

ELib

• A pure-Java library

• ELib provides for inter-process capability-secure distributed programming.

• Its cryptographic capability protocol enables mutually suspicious Java processes to co-operate safely

• And its event-loop concurrency and message pipelining enable high performance deadlock free distributed pure-object computing.

Page 4: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

E Language

• The E language provides a convenient and familiar notation for the ELib computational model

• This notation expands into Kernel-E, a minimalist lambda-language much like Scheme or Smalltalk.

• Objects written in the E language are only able to interact with other objects according to ELib's semantics, enabling object granularity intra-process security, including the ability to safely run untrusted mobile code (such as caplets).

Page 5: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

Kernel-E

• The E language is specified in layers. • At the bottom is the Kernel-E language. • The Kernel-E language is a subset of the regular E

language • The remainder of E's grammar outside the kernel subset

is E's sugar. • The semantics of the sugar is defined by canonical

expansion to Kernel-E. • This expansion happens during parsing• E parse trees only contain nodes defined by Kernel-E, so

only these are executed by the virtual machine (Java).

Page 6: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

E Language Grammar

• Expressions by precedence and associativity

• Primitive Expressions (no precedence needed)

• Patterns (including variable declaration)

• Quasi-Literal Expressions and Patterns

• Methods and Matchers (object behavior)

• Lexical Grammar (Tokens)

Page 7: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

Perspectives unified under E

• Objects [encapsulation, polymorphism, modularity]

• Capability Security [constraints]

• Cryptographic Protocol [Pluribus]

• PKI [SPKI]

• Game Rules

• Financial Bearer Instruments Gra

nove

tter O

pera

tor

Page 8: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

From Objects to Capabilities

• A capability is a pairing of a designated process with a set of services that the process provides

• When different capabilities make different behaviors from the same process, we can view the process as a composite and each of its capabilities as a facet

• Patterns of Cooperation Without Vulnerability • Only Connectivity Begets Connectivity

– By Introduction / Parenthood / Endowment / Initial Conditions• Absolute Encapsulation • All Authority Accessed Only by References

• Rights Amplification

Page 9: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

Capabilities as a PKI

In SPKI, there is no way of confining the Issuer, to limit the entities that it can authorize.

The lack of a line between Issuer and Subject in the diagram reflects this situation

Page 10: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

Capabilities as a PKI contd…

• Another difference is that the resource need not be an object. The verifier which checks the authorization acts as a gatekeeper, in the same way that Pluribus acts as a gatekeeper to distributed E objects

• In an SPKI system, auditing who performed an action and who authorized it fall naturally out of the public key structure

• Auditing in a Pluribus system requires the introduction of intermediary objects accompanying each rights transfer in order to keep track of the authorization path

Page 11: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

Capabilities as a PKI contd…

• Because an SPKI authorization does not include a direct designation of the resource being authorized, it introduces the possibility of a confused deputy

• A confused deputy uses an authorization given to it by one party to access a resource designated by a different party. In so doing, the confused deputy performs an unintended rights transfer

• Authorization in SPKI is expensive. – At a minimum each authorization decision requires two signature

verification operations by the verifier. – The signature on the certificate must be checked, and the

signature of the Subject, proving possession of the private key, must also be checked.

Page 12: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

Capabilities as a PKI contd…

• In addition, the Subject must sign a challenge from the verifier if the system is to remain safe from replay attacks.

• Compare this cost with Pluribus, where the public key operations are limited to connection establishment.

• In recognition of this cost, SPKI provides the Certificate Result Certificate which permits an entire certificate chain to be collapsed into one certificate.

Page 13: And SPKI Vishwas Patil STCS, TIFR, Mumbai, INDIA vtp@tifr.res.in vishwas.

Pluribus