SCC Overview

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

SCC aims to allow verification of a binary object's identity.

SCC verifies a binary object's source code signatures, which uniquely identifies the binaries sources.

Motivation

Certificate based security, is not secure

Certificated are designed for identification Certificate based security is based on the idea is that if you know who created one application 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.

Certificates may grant extra privileges that a simple application should not have, this makes certified application break outside the java 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 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.

Design

Use source and binary signature tags stored in accessible source code repository (SCR).

The source tag is provided at build time.

The binary tags are generated for each build and target 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 binary identification.

SCC then validates whether both exist and are equal as stored on the SCR.

Revocation

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