SCC Overview: Difference between revisions

From JogampWiki
Jump to navigation Jump to search
No edit summary
 
(27 intermediate revisions by 2 users not shown)
Line 18: Line 18:
== Overview ==
== Overview ==


SCC aims to allow verification of a binary object's identity.
<blockquote>
''Are You Who You Say You Are?''
</blockquote>
This question doesn't make clear ''Who is who'', or ''who are we talking about''?


SCC verifies whether it's binary object's signature  
When attempting to run a binary object on your system, users need to trust the binary
matches it's source code signatures it claims.
and its original source code.
 
The question should ask for the ''authorship'' of the binary and it's assumed source code,
hence SCC authenticates the binary against the source code it claims to be originated from.
 
SCC answers:
<blockquote>
'''''This binary is produced by this set of source code, which is trusted by these people.'''''
</blockquote>
 
SCC verifies whether a binary object's signature
matches its assumed source code signatures.
 
SCC provides a list of personal signatures who trust this source code,
as well as a list of personal signatures who trust this binary object.
Hence SCC incorporates a [https://en.wikipedia.org/wiki/Chain_of_trust chain of trust].


== Motivation ==
== Motivation ==
''SCC'' was conceived in [{{SERVER}}/log/irc/jogamp_20130912050611.html#l8 this discussion in our IRC channel, 2013-09-12].


=== What's wrong with current binary distribution models? ===
=== What's wrong with current binary distribution models? ===


=== Certificate based security, is not secure ===
=== Certificate based security, is not secure ===
Certificated are designed for identification.
Certificates are designed for identification.
Certificate based security is based on the idea is that if you know who the author is you can trust the binary’s this person hands out. The fallacy with certificate based security thinking is that people who own a certificate identity do not automatically write secure code.
Certificate based security is based on the idea that if you know who the author is you can trust the binary’s this person hands out. The fallacy with certificate based security thinking is that people who own a certificate identity do not automatically write secure code.


See [[#Overview|our overview]], how ''SCC'' solves this issue.
==== Signed ''Applets'' are privileged ====
Certificates may grant extra privileges that a simple application should not have, this makes certified application break outside a security sandbox. An application that is run outside the sandbox is naturally less secure compared to one unsigned application running inside the sandbox.
Certificates may grant extra privileges that a simple application should not have, this makes certified application break outside a security sandbox. An application that is run outside the sandbox is naturally less secure compared to one unsigned application running inside the sandbox.
http://docs.oracle.com/javase/tutorial/deployment/applet/security.html
http://docs.oracle.com/javase/tutorial/deployment/applet/security.html


Revocation is hard using certificate based security because you need to tell the supplier of the application to revoke and re-deploy all its applications using a new certificate if a flaw is found in one of the authors applications.
Revocation is hard using certificate based security because you need to tell the supplier/author of the application to revoke and re-deploy all its applications using a new certificate if a flaw is found in one of the authors applications.
 
Hence it is considered most ''secure'' '''not to sign''' an ''Applet'' and hence not to grant extra privileges,
which would allow the ''Applet'' to reach out of its otherwise considered secure sandbox.
 
=== Further Readings ..  ===
The authors of the following references came to the same conclusions independently.
 
* http://www.cert.org/blogs/certcc/2013/04/dont_sign_that_applet.html - by Will Dormann: Don't Sign that Applet!
* [https://www.securecoding.cert.org/confluence/display/java/ENV00-J.+Do+not+sign+code+that+performs+only+unprivileged+operations;jsessionid=2F08DC1B78E8122152A6ADC2EA38B14B ENV00-J. Do not sign code that performs only unprivileged operations]
* [http://www.gnu.org/philosophy/can-you-trust.html Can You Trust Your Computer?], by Richard Stallman


== Design ==
== Design ==


Use source and binary signature tags stored in accessible source code repository (SCR).
Each tag has a unique cryptographic signature, either providing a hash value over source code or binary objects.
 
Source and binary tags are stored in an accessible source code repositories (SCR).


The source tag is provided at build time.
The source tag is provided at build time.


The binary tags are generated for each build and target and retroactively added
The binary tags are generated at each build and retroactively added to the SCR.
to the SCR.


The binary contains both, source and binary tags,
The binary contains both, source and binary tags,
i.e. it claims a source code identification while providing it's binary identification.
i.e. it claims a source code identification while providing it's own binary identification.
 
Developers may associate their personal signature to the source tag '''if''' they trust its code.
 
Developers may associate their personal signature to the binary tags '''if''' they trust its code and build.
 
''Auth-1'': ''SCC'' validates the binary against its tag and whether both tags exist in the SCR and are equal.


SCC then validates whether both exist and are equal as stored on the SCR.
''Auth-2'': ''SCC'' may show personal signatures associate to the source and binary tags,
allowing the user to make a choice based on the [https://en.wikipedia.org/wiki/Chain_of_trust chain of trust].


=== Revocation ===
=== Revocation ===


Revocation of single binary signatures are possible by simply removing
Revocation of a single binary tag is possible by simply removing
a binary signature from the SCR.
the binary tag from the SCR.

Latest revision as of 16:31, 12 September 2013

Source Certification Contract (SCC)

Question:

Are You Who You Say You Are?

Answer:

Trust the Source, User

The acronym SCC is not related to the Sirius Cybernetics Corporation or any of their superficial design flaws :)

Overview

Are You Who You Say You Are?

This question doesn't make clear Who is who, or who are we talking about?

When attempting to run a binary object on your system, users need to trust the binary and its original source code.

The question should ask for the authorship of the binary and it's assumed source code, hence SCC authenticates the binary against the source code it claims to be originated from.

SCC answers:

This binary is produced by this set of source code, which is trusted by these people.

SCC verifies whether a binary object's signature matches its assumed source code signatures.

SCC provides a list of personal signatures who trust this source code, as well as a list of personal signatures who trust this binary object. Hence SCC incorporates a chain of trust.

Motivation

SCC was conceived in this discussion in our IRC channel, 2013-09-12.

What's wrong with current binary distribution models?

Certificate based security, is not secure

Certificates are designed for identification. Certificate based security is based on the idea that if you know who the author is you can trust the binary’s this person hands out. The fallacy with certificate based security thinking is that people who own a certificate identity do not automatically write secure code.

See our overview, how SCC solves this issue.

Signed Applets are privileged

Certificates may grant extra privileges that a simple application should not have, this makes certified application break outside a security sandbox. An application that is run outside the sandbox is naturally less secure compared to one unsigned application running inside the sandbox. http://docs.oracle.com/javase/tutorial/deployment/applet/security.html

Revocation is hard using certificate based security because you need to tell the supplier/author of the application to revoke and re-deploy all its applications using a new certificate if a flaw is found in one of the authors applications.

Hence it is considered most secure not to sign an Applet and hence not to grant extra privileges, which would allow the Applet to reach out of its otherwise considered secure sandbox.

Further Readings ..

The authors of the following references came to the same conclusions independently.

Design

Each tag has a unique cryptographic signature, either providing a hash value over source code or binary objects.

Source and binary tags are stored in an accessible source code repositories (SCR).

The source tag is provided at build time.

The binary tags are generated at each build and retroactively added to the SCR.

The binary contains both, source and binary tags, i.e. it claims a source code identification while providing it's own binary identification.

Developers may associate their personal signature to the source tag if they trust its code.

Developers may associate their personal signature to the binary tags if they trust its code and build.

Auth-1: SCC validates the binary against its tag and whether both tags exist in the SCR and are equal.

Auth-2: SCC may show personal signatures associate to the source and binary tags, allowing the user to make a choice based on the chain of trust.

Revocation

Revocation of a single binary tag is possible by simply removing the binary tag from the SCR.