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

In the world of software development, there are times when you need to prove that a piece of software works as intended without sharing its source code. This article explores a method that allows you to demonstrate software properties while keeping the source code private.

Understanding the Challenge

When working with software, especially in projects involving proprietary components or sensitive data, sharing the source code can be risky. The usual options are not very appealing. You might have to share the entire implementation, which can expose your intellectual property. Alternatively, you might have to trust a report that claims the software has been verified, but that often lacks transparency.

Introducing SJV and SJP

To address these challenges, a new approach is being explored using two key concepts: SJV and SJP.

• SJV (Software Verification Contract): This is a document that outlines the properties the software should exhibit. It specifies what needs to be proved without revealing how the software is built.
• SJP (Software Justified Proof): This is the evidence produced during the verification process. The SJP shows that the software meets the properties defined in the SJV.

The basic idea is to separate the implementation of the software from the contract and the proof. This means the source code stays with the developer, while the SJV and SJP can be shared with the recipient.

How It Works

Here’s a simplified breakdown of how this process works:

Step 1: Define the SJV

The developer creates an SJV that describes the expected properties of the software. For example, it might state that a certain value should never exceed a defined maximum.

Step 2: Generate the SJP

After verifying the software against the SJV, the developer produces an SJP. This artifact contains the verification evidence, including:

• A verification manifest
• Information about inputs and configurations
• Verification results
• Mathematical obligations
• Integrity data
• A manifest signature

Step 3: Share the SJV and SJP

The developer shares the SJV and SJP with the recipient. The recipient can then inspect the SJV to understand the claimed properties and check the integrity of the SJP.

Step 4: Verify the Claims

Using tools like Z3, the recipient can replay the mathematical obligations stored in the SJP. This allows them to verify whether the claims made in the SJV hold true without needing access to the source code.

The Trust Boundary

One important concept in this process is the trust boundary. This is a line that separates areas with different levels of trust in a system. For instance, the developer trusts their own code but may not trust the recipient with the source code. The trust boundary helps clarify what can be verified independently and what requires trust.

There are two key statements to consider:

• Statement A: The mathematical obligations are valid.
• Statement B: These obligations were generated from the specific private implementation claimed by the developer.

The SJP can help establish Statement A, but it does not confirm Statement B without the source code.

Limitations and Considerations

While this method provides a way to verify software properties without sharing source code, there are limitations. The recipient must ensure that the properties outlined in the SJV are indeed what they care about. A successful verification only confirms that the defined properties hold within the modeled scope; it does not guarantee that the software is free of bugs.

To strengthen the proof of provenance, additional mechanisms can be put in place, such as:

• Having an independent auditor inspect the source code.
• Generating the SJP in a controlled environment.
• Disclosing the source code only to trusted third parties.

Conclusion

The approach of using SJV and SJP allows for a more secure way to verify software properties without the need to share sensitive source code. This method is particularly relevant in today's software landscape, where trust and security are paramount.

Merits

• Enables verification without exposing source code.
• Allows clear separation of claims, evidence, and implementation.
• Provides a structured proof that can be independently verified.

Demerits

• Does not guarantee the software is bug-free.
• Relies on the recipient understanding and trusting the SJV.
• Requires additional mechanisms for proof of provenance.

Caution

This article is intended for educational purposes. Any placeholder values must be replaced with actual data in practical applications. Readers should verify claims against the original source before relying on them.

Frequently asked questions

• What is SJV? — SJV stands for Software Verification Contract, which outlines the properties a software module should exhibit.
• What is SJP? — SJP stands for Software Justified Proof, an artifact containing evidence that a software module meets its specified properties.
• Why is separating SJV and SJP important? — It allows verification of software properties without exposing the source code, enhancing security and trust.
• How can verification be done without source code? — By using tools like Z3 to replay mathematical obligations stored in the SJP.
• What is a trust boundary? — A trust boundary is a conceptual line that separates areas of different trust levels within a system.
• Can SJP guarantee software correctness? — No, SJP verifies specific properties but does not guarantee that the software is free of bugs.

Tags

#software #verification #trust-boundary