Contextualizing SSP
Secure, Simple, Powerful. That is what SSP, a multisig, non-custodial hot wallet, delivers to its users as the most secure browser wallet on the market. We will examine the reasons why SSP outperforms every other browser wallet in the current Web3 landscape by reviewing its robust security features.
Securing digital assets for users is SSP’s top priority, and it accomplishes this through multisig with two-key authentication sign-ins, open-source and deterministic builds, regular security audits, and a new integration with the security framework LavaMoat. In today’s article, we will be covering these features and more, so let’s dive in!
SSP Security Features
On-chain Multisignature for Two-Key Authentication
Most crypto wallets, such as MetaMask, Phantom, and Exodus, don’t require multiple signatures for authentication and transaction signing. They often support multi-sig authentication, where two private keys are used to verify a transaction initiated by the wallet owner, but don’t require it. Therefore, a single mistake during sign-in or transaction signing can result in a hack or loss of funds.
SSP employs a unique two-device BIP-48 multisignature, where both device key pairs are derived from the same master private key, ensuring backward compatibility between devices for sign-in, enabling complex authentication setups.
SSP two-key multisignature authentication requires both a browser wallet signature on one device and a mobile wallet signature on another to sign and approve transactions.
Utilizing a two-device attestation for transaction signing, where a browser SSP account and a mobile SSP account are required to verify on-chain events, creates redundancy, eliminating any single points of failure.
To sign a single transaction or gain access to the wallet account, users need private keys from both devices, so wallet sign-ins become impossible to compromise with just a single private key.
Open-Source Audited Code
Open-source vs. closed-source code in tech has been and will continue to be an ongoing debate, as both approaches have their pros and cons. Open-source software solutions bring transparency while inviting community-sourced innovation, but can lack dedicated support and involve a steep learning curve for users.
While closed-source software solutions are ready-to-ship and compliance-aligned, they are expensive for users to adopt and foster vendor lock-in.
In line with decentralization and open access, SSP is open-source, meaning its codebase is adoptable and auditable by anyone. Users can verify, build on, and iterate SSP’s stack, ensuring that it stays Secure, Simple, and Powerful according to every party that uses it. SSP being open-source enables anyone to review its stack to surface errors, maintaining wallet integrity and trust.
SSP Wallet underwent an extensive and rigorous security audit by the renowned blockchain security firm, Halborn. In a commitment to transparency, all of SSP’s source code and component features have been thoroughly audited in a publicly available security report.
Deterministic Docker Builds
Now, in addition to being open-source, SSP utilizes deterministic Docker builds to ensure that users can independently verify their download matches the build published in SSP’s official source code.
A deterministic Docker build is when a Docker image’s source code is constructed in a way where its inputs are immutable, so that when it’s reconstructed, its build will be byte-for-byte the same, regardless of what environment the build is executed in.
Docker containers provide isolated environments for building software solutions that are separate from the host operating system, enabling deterministic builds and reproducibility across different hosts. SSP uses cryptographically signed release checksums to verify the integrity and authenticity of replicated Docker images.
SSP deterministic Docker builds eliminate supply chain attack vectors (where a hacker targets a less secure third-party vendor in a company’s supply chain) through inherent tampering detection.
If a hacker modifies or injects malicious code into the Docker image build process, the resulting image will differ from the deterministically built original image. When the cryptographic hashes of the modified image and the trusted, original Docker image are compared, unauthorized modifications to the build processes become obvious.
Zero Data Storage
SSP maintains a strict no-server-storage policy, meaning private keys, seed phrases, and transaction histories live exclusively on the user’s two sign-in devices, featuring military-grade encryption optimized for maximum wallet security.
A no-server-storage policy stipulates that sensitive user data is not stored on a hardware or software provider’s servers, but instead is stored locally on the user’s device.
Due to how SSP utilizes dual-device multisig authentication for transaction signing, a zero-data storage policy between multiple devices ensures that sensitive data and key pairs remain distributed, providing enhanced protection. A zero-data storage policy enables true self-custody as the user controls their sensitive data.
Additionally, this policy eliminates centralized attack vectors because there is no single, high-value data store, as the private keys are spread across separate sign-in devices, thereby reducing the attack surface area.
LavaMoat Integration
SSP has integrated the LavaMoat security framework, which provides runtime compartmentalization for JavaScript modules, allowing them to maintain wallet integrity even if dependencies are compromised.
LavaMoat employs an architectural design that breaks down a software system into isolated, self-contained compartments, serving as execution environments that remain separate when code runs or computing tasks are executed.
These compartmentalized execution environments operate according to the principle of least privilege, where a system only runs with the minimum level of permissions required to perform a task.
LavaMoat utilizes policy-based access control, where explicit permissions define what each execution environment can access regarding wallet dependencies, Docker builds, and user data. Runtime compartmentalization is a zero-trust architecture, meaning that no execution environment is trusted by default, creating a need for strict access control and inherent layers of security.
Conclusion
By utilizing two devices for key authentication, where both a mobile and browser SSP account are required for transaction signing, SSP Wallet eliminates single points of failure. Being open-source allows for transparency, meaning that anyone can review and iterate on SSP’s stack.
Aside from being regularly audited by accredited blockchain security firms such as Halborn, SSP employs deterministic Docker builds, which enable users to verify downloads against SSP’s doxxed source code.
Additionally, SSP has a zero-data-storage policy for pure self-custody. Sensitive user data and private key pairs are stored exclusively on the devices used for dual-sign-in attestation, and not on SSP servers.
Finally, SSP has integrated the LavaMoat security framework, which maintains strict access permissions and compartmentalizes JavaScript modules, ensuring wallet security remains intact even if dependencies are compromised.
SSP doesn’t treat security as a bonus feature; it is fundamental to the wallet and baked into every aspect of its development. Furthermore, every time SSP implements something new, the questions are always, ‘How can this make the wallet more secure?’ and ‘How can this better protect user assets?’ So, your crypto security is our top priority. Try SSP Wallet today.