wiz

We’ll be sharing more about this soon. But internally nobody that can push app code can push server code to production. And nobody that can push app or server code can push firmware code. And you need at least 2 people on the Bitkey team (not anyone at block) to push to any of them. Nobody is in more than one group. So for rogue employees to write code that attempts to compromise two keys would take collusion of at least 4 people just to attempt it. But in reality even more because our security team at Block (outside of Bitkey) controls gates that review all code with LLMs before they go into the release and if it finds a security issue it blocks the release PR from merging. So now you’ve got probably 6-7 people on the mix. Plus if it were done through our normal release pipeline any Android code that’s malicious would be pushed to the public to create visibility. We have people scanning our public repository constantly. Both internally and externally. And our mobile app is 98% shared mobile code via Kotlin Multiplatform. Which means there’s no iOS only repo to go make changes in. You’ve gotta then find a way to get malicious iOS code into the release pipeline and you’ve still then only got a shot at one key in this hypothetical situation. Our release pipeline is also hardened in that we do reproducible builds internally. So we build the version of the app in 3 distinct build environments and if any of them don’t match the others it halts. Ok so now you’ve gotta find a way to compromise 3 distinct/different build systems each with their own security pipelines including one run in the local machine of the release manger which changes hands periodically, and do in a way that’s not detectable to all the layers of safeguards we have. And that’s still just trying to get to one key. And if you think that’s me trying to shut down a conversation about possibility space, I’m not. I’m saying rogue Bitkey employees doing this would be extraordinarily difficult. We all see each others’ PRs. We all helped build these safeguards because don’t trust verify is in our veins. And yes I know this does not fully address what if Block decides to risk its Fortune 500 business on rigging its own customers. If that’s what you’re worried about, keep reading. Long conversations about possibility space is what this team thrives on. And we’re never done. Which means we’re looking at ways that you wouldn’t even need to trust me on the above to get the protections against app-key compromise some people in this thread are asking for. Hence our discussions on a two hardware option for those that care a lot about this specific area. And some other interesting related ideas we’ll share if they pan out. Whatever you do, whether you choose Bitkey or not, go with a solution built by people that care this much about protecting you from themselves. Hope this helps!