Proof Without Sharing Source Code: SJV, SJP, and the Trust Boundary

In situations where source code must remain confidential, demonstrating properties of a software module can be challenging. This issue arises in scenarios involving proprietary libraries, supplier components, security-sensitive software, licensed IP, and implementations shared between organizations with differing trust boundaries.

Traditionally, the options are to either disclose the implementation or rely on a report of internal verification. However, a new approach called Sekura JS aims to separate the implementation from the contract and the proof artifact.

The model consists of three components: source code, which remains with the developer; SJV, which describes the properties that should hold; and SJP, which carries the evidence generated by verification. SJV defines what needs to be proved, while SJP contains the evidence. Importantly, the source code does not need to be shared in this process.

While a verifier can replay the mathematical obligations stored in an SJP without seeing the source code, this alone does not prove that the obligations were correctly generated from the specific closed-source implementation claimed by the developer. This distinction is crucial.

The relationship between these components can be visualized as follows: private implementation | verified against SJV contract v SJP. The implementation answers the question of how the module is built, the contract defines what behavior is claimed, and the proof artifact presents the verification evidence for those claims.

This separation of concerns is beneficial even when source code disclosure is not an issue. However, it becomes particularly important when dealing with proprietary or sensitive code.

Formal verification does not guarantee universally correct programs; rather, it proves specific properties within the modeled scope. The contract itself must be reviewable by the recipient before the verification result is considered valid. The recipient should first ask whether the claimed properties are relevant to their concerns.

An SJP, or Sekura Justified Proof, is produced after verification. It carries verification evidence separately from the implementation. An SJP may include a verification manifest, information about inputs and configuration, verification results, SMT obligations, integrity data, and a manifest signature. The key point is that the mathematical obligations can be transported with the package, allowing independent verification without needing the developer's statement of trust.

The verification process involves using Z3 for verification and CVC5 for cross-checking, if necessary. When verifying an SJP, the system can check its structural validity, integrity checks, and signature validity using Ed25519. However, this verification does not confirm whether the SMT obligations came from the exact private source code claimed by the developer. This creates an explicit trust boundary between the private source code and the proof generation.

There are four layers to consider in this verification model: the contract, which defines the claimed properties; mathematical proof, which verifies the stored obligations; signature, which ensures the manifest matches the signature; and provenance, which determines if the obligations truly originated from the claimed implementation. Mixing these layers can lead to misleading security claims, so it is essential to keep them separate.