Cubist’s Post

Why is it dangerous to write key management code in JavaScript? Writing safe cryptographic code requires fine-grained control over how that code executes—and JavaScript makes such fine-grained control almost impossible. Instead of leaving code execution in control of the programmer, JavaScript code executes on top of a special-purpose piece of software called the JavaScript engine, which plays all kinds of tricks in the name of speed (as opposed to safety). The JavaScript engine may, for example:  - Indiscriminately replicate your keys - Leave secrets strewn about long after they’re useful       - Optimize safe code into unsafe code that leaks your secrets The bottom line: Don’t sacrifice security! JavaScript is a great language for building UIs, and you should use it for that. JavaScript is a terrible choice for writing cryptographic code to handle private keys.

Come join our growing team! Cubist is searching 🔎 for our first Head of Sales. This is a unique opportunity to go after a hot market with a young product already seeing traction 📈 from banks and other serious players. CubeSigner, our secure key management platform, lets institutions, DeFi protocols, and Web3 projects easily interact with digital assets without cutting corners on security. Help us build a world where no one is forced to use hot wallets to get great UX or cumbersome cryptographic protocols to get security! If this sounds like fun, we’d love to hear from you. Learn more and apply here: https://lnkd.in/gUFJ44Tk

When using a browser-based wallet, exactly how secret are secret keys? It’s plain and simple. 🔤 Plaintext, actually. Browser-based wallets perform all of their operations on the browser-side, directly and dangerously pulling plaintext keys into browser memory (regardless of how the keys are sharded or stored at rest!) alongside potentially malicious JavaScript. Here’s why it’s risky to use wallets that handle private keys in the browser: 1/ Key Exposure 🔓 Browser-based wallets sign transactions in the browser, potentially exposing plaintext secret keys to hackers. And in the browser, hackers come from all over: from the thousands of JavaScript scripts running on many websites, to browser extensions, to malware. 2/ Phishing Attacks 🖱 Attackers love plaintext keys. They trick users into clicking malicious links and loading malicious content, putting users just one click away from getting their keys stolen. 3/ Memory Safety Bugs 🐞 No matter how cautious you are, browser vulnerabilities can leak keys. Check out the list of zero-days exploited at Trend Micro Zero Day Initiative’s Pwn2Own hacking contests—it’s long! 4/ JavaScript Quirks 🚨 Browser wallets don’t typically use the underlying browser’s built-in support for crypto, largely because the WebCrypto API doesn’t support the necessary curves. Instead, they’re written in JavaScript, a language that’s unsafe for writing cryptographic code—and full of side-channel vulnerabilities. Our advice for builders: Separate key management from your UI. Opt for safer key management that signs transactions away from attackers, not directly in the browser. Your users will thank you! Check in with us next week as we take a closer look at the risks of implementing sensitive key-handling code in JavaScript. 

Today we’re excited to share our writeup on slashing risk management in restaking: https://lnkd.in/gEXw9HT5 In restaking—as in standard Ethereum staking—it's impossible to distinguish between malicious behavior and honest mistakes. The likelihood of mistakes and misconfigurations scales with the number of AVSes an operator opts into: the more complex devops setups they need to run and configure, the more likely it is that things will go wrong—and that they’ll get slashed. “Well, that’s what anti-slashing is for,” you might say. But AVSes define their own slashing conditions—and not all slashing conditions can be approximated and enforced using anti-slashers. In practice, operators have to trade off between their validators' performance (availability) on AVS protocols that are incompatible with anti-slashers and the security (slashing) of these validators across all the AVSes they opted into. Finally, when slashing happens in restaking, it isn’t necessarily isolated; getting slashed by one AVS may correlate with getting slashed on other protocols, so a bug in one AVS client impacts others AVSes, too. A proper anti-slashing setup mitigates these risks on AVSes which have designed their protocols to be anti-slashable, but this doesn’t mean just firing up an instance of Web3Signer. (More in the blog post! We’ve been thinking about anti-slashing and staking security for a long time…). #ethstaking #restaking #eigenlayer #ethereum #slashing #proofofstake #validators #ethereumvalidator #beaconchain

We designed CubeSigner to protect Ethereum validator operators from insider threats, validator compromise, operational mistakes, and client bugs. See a full description of CubeSigner’s architecture on the Amazon Web Services (AWS) Blog: https://lnkd.in/gQcQUxfU Signing a validation message with CubeSigner takes three steps. The system: 1️⃣ Accepts a validator’s validation message via an HTTP interface based on Amazon API Gateway, making sure that it only signs requests from authenticated validator clients. 2️⃣ Checks if the message is slashable using a signing history stored in DynamoDB. CubeSigner atomically records the validation messages it signs for each epoch, ensuring that the signer will not sign two conflicting messages with the same key. 3️⃣ Signs the message—as long as it’s non-slashable—using keys secured by AWS KMS and Nitro Enclaves. CubeSigner’s virtual HSM encrypts all signing keys using a KMS-based key wrapping key that is sealed to the secure enclave, which guarantees that the enclave is the only component that can decrypt keys. Whenever CubeSigner gets a request to sign a transaction, it pulls the encrypted signing key and the key wrapping key into the enclave, decrypts the signing key, signs the transaction, and returns the signature to the user. Not only does this design protect keys 🔐 from theft (even by insiders!), it also prevents slashing ⚡ —including cases of signer or OS updates, machine failures, and network interruptions. #ethereum #security #blockchainsecurity #slashing #proofofstake #validators #ethereumvalidator #ethstaking #beaconchain

Amazon Web Services (AWS) is the foundation of our CubeSigner key management platform because it’s the only cloud provider that gives us the primitives we need to address the security, correctness, and availability challenges faced by Web3 teams managing private keys 🔑 —including Ethereum validator operators. We’re excited to share more about CubeSigner’s non-custodial architecture (and application to validators!) in a blog post by Cubist founders Fraser Brown and Deian Stefan, co-authored by AWS Blockchain Architect David Dornseifer. When building out CubeSigner for validators, we had three main goals: 1️⃣ Prevent attackers or malicious insiders from stealing or misusing Eth1 and Eth2 keys. 2️⃣ Protect operators from slashing by enforcing to-spec behavior. 3️⃣ Help operators achieve their latency, reliability, and availability targets. Our system uses: secure hardware—Nitro Enclaves and KMS—to keep keys locked away from attackers; a policy engine backed by DynamoDB to prevent slashing; and AWS’s highly reliable, highly available services to make sure validators are always online. Read the full post here: https://lnkd.in/gQcQUxfU A big thank you to our partners at AWS 🤝 David Dornseifer, Yinal Ozkan, Brad Feinstein, Josh Howitz ☁

“We need people to be able to say: if I stake with this operator, then I'm exposed to these things and these are the measures that they're taking to reduce that risk.” Thrilled to have been part of the Secure Staking Alliance event at #ETHDenver2024! Bringing together many of the industry’s top leaders under one roof, Cubist and our fellow members dissected (re)staking’s current and impending security challenges and what they mean for the evolution of our ecosystem. The afternoon sparked new collaborations, leaving us excited about the future as we continue on our mission to make (re)staking more secure for all. Interested in joining us next time? Learn more at https://lnkd.in/dVBTPAQb

Did you know that Cubist’s original pitch had nothing to do with private keys? Cubist Co-Founder & COO Ann S. talks about her background in fraud operations and the process she used to ensure we were building something people need. Watch the full episode by Protocol Labs here: https://lnkd.in/gMxJEUpj