Search the Community

This post was contributed by BastionZero. Giving people the ability to sign messages under their identity is extremely powerful. For instance, this functionality lets you SSH into servers, sign software artifacts, and create end-to-end encrypted communications under your single sign-on (SSO) identity. The OpenPubkey protocol and open source project brings the power of digital signatures to both people and workloads without adding trusted parties. OpenPubkey is built on the OpenID Connect (OIDC) SSO protocol, which is supported by major identity providers, including Google, Microsoft, Okta, and Facebook. This article will explore how OpenPubkey works and look at three use cases in detail. What can OpenPubkey do? Public key cryptography was invented in the 1970s and has become the most powerful tool in the security engineering toolbox. It allows anything holding a public key, and its associated signing key, to create a cryptographic identity. This identity is extremely secure because the party cannot only use their signing key to prove they are who they say they are but also sign messages under this identity. Servers often authenticate themselves to people using public keys associated with the server’s identity, yet the process rarely works the other way. People rarely authenticate to servers using public keys associated with a person’s identity. Instead, less secure authentication methods are employed, such as authentication secrets stored in cookies, which must be transmitted on every request. Let’s say that Alice wanted to sign the message “Flee at once — all is discovered” under her email address alice@example.com. How would she do it? One approach would be for Alice to create a public key (PK) and signing key (SK) and then publish the mapping between her email and the PK. This approach has two problems. First, you and everyone verifying this message must trust that the webpage has honestly mapped Alice’s email to her public key and has not maliciously replaced her public key with another key that could be used to impersonate Alice. Second, Alice must now protect and manage the signing key associated with this public key. History has shown that users can be terrible at protecting signing keys. Probably the most famous example is of the man who lost a signing key controlling half a billion dollars worth of Bitcoin. Human authentication on the web was originally supposed to work the same way as server authentication. Much like a certificate authority (CA) issues a certificate to a server, which associates a public key with the server’s identity (`example.com`), the plan was to have a CA issue a client certificate to a person that associates a public key with that person’s identity. These client certificates are still around and are well-used for certain applications, but they never caught on for widespread personal use, likely because of the terrible user experience (UX) of asking people to secure and manage secret signing keys. OpenPubkey addresses both of these problems. It uses your identity provider to perform the mapping between identity and your public key. Because you already trust your identity provider, having your identity provider perform this mapping does not add any new trusted parties. For instance, Alice must already trust her identity provider, Example.com, to manage her identity (alice@example.com), so it is natural to use Example.com to perform the mapping between Alice’s public key and her Example.com identity (alice@example.com). Example.com already knows how to authenticate @example.com users, so Alice doesn’t need to set up a new account or create new authentication factors. Second, to solve the problem of lost or stolen signing keys, OpenPubkey public keys and signing keys are ephemeral. That means the signing keys can be deleted and recreated at will. OpenPubkey generates a fresh public key and signing key for a user every time that user authenticates to their identity provider. This approach to making public keys ephemeral removes one of the most significant UX barriers to authenticating people with public keys. It also provides a security win; it creates a much smaller window of exposure if a signing key is stolen, as signing keys can be deleted when the user idles or logs out. How does OpenPubkey work? Let’s return to our situation: Alice wants to sign the message “Flee at once — all is discovered” under her identity (alice@example.com). First, Alice’s computer generates a fresh public key and signing key. Next, she needs her identity provider, Example.com, to associate her identity with this public key. How does OpenPubkey do this? To understand the process, we first need to provide details about how SSO/OpenID Connect works. Example.com, which is the identity provider for @example.com, knows how to check that Alice is really alice@example.com. Example.com does this every time Alice signs into Example.com. In OIDC, the identity provider signs a statement, called an ID Token, which roughly says “this is alice@example.com”. Part of the authentication process in OIDC allows the user (or their software) to submit a random value that will be included in the issued ID Token. Alice’s OpenPubkey client puts the cryptographic hash of Alice’s public key into this value in her ID Token. Alice’s OpenPubkey client modifies the ID Token into an object called a PK Token, which essentially says: “this is alice@example.com and her public key is 0xABCE…“. We’re skipping a few details of OpenPubkey, but this is the basic idea. Now that Alice has a PK Token signed by Example.com, which binds her public key to her identity, she can sign the statement “Flee at once — all is discovered” and broadcast the message, the signature, and her ID Token. Bob, or anyone else for that matter, can check whether this message is really from alice@example.com, by checking that the ID Token is signed by Example.com and then checking that Alice’s signature matches the public key in the ID Token. OpenPubkey use cases Now let’s look at OpenPubkey use cases. SSH OpenPubkey is useful for more than just telling your friends that “Flee at once — all is discovered.” Because most security protocols are built on public key cryptography, OpenPubkey can easily plug human identities into these protocols. SSH supports the authentication of both machines and users with public keys (also known as SSH keys). However, these SSH keys are not associated with identities. With an SSH key, you can say “allow root access for key 0xABCD…”, but not “allow root access for alice@example.com.” This presents several UX and security problems. As mentioned previously, people struggle with managing their secret signing keys, and SSH is no exception. Even more problematic, because public keys are not associated with identities, it is difficult to tell if an SSH key represents a person or machine that should no longer have access. As Tatu Ylonen, the inventor of SSH, writes in his recent paper Challenges in Managing SSH Keys — and a Call for Solutions: “In analyzing SSH keys for dozens of large enterprises, it has turned out that in many environments 90% of all authorized keys are no longer used. They represent access that was provisioned, but never terminated when the person left or the need for access ceased to exist. Some of the authorized keys are 10-20 years old, and typically about 10% of them grant root access or other privileged access. The vast majority of private user keys found in most environments do not have passphrases.” OpenPubkey can be used to solve this problem by binding SSH keys to user identities. That way, the server can check whether the identity (alice@example.com) is allowed to connect to the server or not. This means that Alice can access her SSH server using SSO; she can log in to Example.com as alice@example.com and then gain access to the server as long as her SSO is valid. OpenPubkey authentication can be added to SSH with a small change to the SSH config. No code changes to SSH are required. To try it out, or learn more about how OpenPubkey’s SSH works, see our recent post: How to Use OpenPubkey to SSH Without SSH Keys. Secure messaging OpenPubkey can also be used to solve one of the major issues with end-to-end encrypted messaging. Suppose someone sends you a message on a secure messaging app: How do you know they are actually that person? Some secure messaging apps let you look up the public key that is securing your communication, but how do you know that that public key is actually the public key of the person you want to privately communicate with? This connection between public key and identity is the core problem that OpenPubkey solves. With OpenPubkey, Bob can learn the public key for alice@example.com by checking an ID Token signed by Example.com, which includes Alice’s public key and her email address. This does involve trusting Example.com, but you generally already have to trust Example.com to SSO @example.com users. While it’s not discussed here, OpenPubkey does support an optional protocol — the MFA cosigner — which removes the requirement of trusting the identity provider. But even without the MFA cosigner protocol, OpenPubkey provides stronger security for end-to-end encrypted messaging because it allows Bob to learn Alice’s public key directly from Alice’s identity provider. Signing container images OpenPubkey is not limited to human use cases. OpenPubkey developers are working on a solution to allow workflows (rather than people) to sign images using GitHub’s identity provider and GitHub Actions. You can learn more about this use case by reading How to Use OpenPubkey with GitHub Actions Workloads. Help us expand the utility of OpenPubkey These three use cases should not be seen as the limits of what OpenPubkey can do. This approach is highly flexible and can be used for VPNs, cosigning, container service meshes, cryptocurrencies, web applications, and even physical access. We invite anyone who wants to contribute to OpenPubkey to visit and star our GitHub repo. We are building an open and friendly community and welcome pull requests from anyone — see the contribution guidelines to learn more. Learn more Read How to Use OpenPubkey with GitHub Actions Workloads. Read How to use OpenPubkey to SSH Without SSH Keys. Fireside chat — Redefining Security Standards: Identity Providers as Certificate Authorities. Get the latest release of Docker Desktop. Vote on what’s next! Check out our public roadmap. Have questions? The Docker community is here to help. New to Docker? Get started. View the full article

A mysterious deposit of 26.9 BTC, worth approximately $1.2 million by current valuations, has been added to the abandoned Genesis wallet. View the full article

Bitcoin has poked its head above $42,000 today, with expected ETF approval and lower interest rates adding fuel to its rise. The good news is GPU mining still isn't regaining traction, and AI remains a bigger threat to gaming GPU prices. View the full article

Cryptocurrency recovery company Unciphered has warned of a security storm coming to the blockchain, with early adopters likely to be particularly affected. Specifically, crypto wallets created between 2011 and 2015 could be vulnerable to Randstorm, an exploit that can gain unauthorized access to crypto wallets by recovering passwords. Unciphered reports that between $1.2-2.1 billion in Bitcoin could be at risk, but warns even this figure could be a conservative estimate. Early Bitcoin adopters could be at risk The report warns the earliest adopters are most likely to be at risk of losing out, because the cryptocurrency is currently worth more than $37,000. At the end of 2015, it was worth a little over $300, meaning wallets might have grown considerably in that time. “Randstorm() is a term we coined to describe a collection of bugs, design decisions, and API changes that, when brought in contact with each other, combine to dramatically reduce the quality of random numbers produced by web browsers of a certain era (2011-2015)," it added. The solution is simple in principle, but many users won’t be pleased that a simple password change won’t suffice. Instead, Unciphered is suggesting that anybody who may be at risk should move their crypto to a new wallet, which it says is good housekeeping when done periodically anyway. While wallet generation is free, transferring Bitcoin will incur a fee. Regardless, paying a fee would be a small price to pay compared with losing the contents of an entire wallet. Those who may be affected can check their public key on the Keybleed website, which is owned by Unciphered, to see whether their wallet is vulnerable to known exploits. More from TechRadar Pro Reckon you’ve downloaded something dodgy? Check out the best malware removalProtect your machine with the best endpoint protection and the best firewallsMillions in crypto has been stolen following LastPass breach View the full article

The valuation of BTC cryptocurrency spiked above $35,000 today, propelled by hopes that the SEC would green-flag ETF investments, but GPU mining is still a long way from being viable. View the full article

Amazon Managed Blockchain (AMB) Query now supports the Bitcoin Testnet to develop and test applications without risking real funds, and Asset APIs for developers to get on-chain properties of smart contracts. View the full article

One of the many innovations to come out of the blockchain space is the Lightning Network, a protocol for sending money on the internet via Bitcoin. Voltage is a Lightning as a Service (LaaS) provider that launched in 2020. Its mission is to provide enterprises with a Lightning Network solution that enables the settlement of real-time payments with near-zero fees, enabling organizations to send and receive payments while creating new experiences and business models. Voltage serves brands that have payments at the core of their business such as financial or fintech companies that need a solution to save on money transfer costs and cross-border payments, or create micropayment experiences for the web. Voltage is working with Google Cloud to expand hosting providers and locations. Through this collaboration, customers can create Bitcoin and Lightning Nodes in Google Cloud at a variety of locations around the world. By using Voltage and Google Cloud, customers can deploy their workloads globally via two leading providers. Voltage helps solve three problems. First, it helps enterprises handle money transfers over the Lightning Network. Second, by using the interoperable Lightning Network standard, businesses can reach a global audience of customers. Finally, Voltage enables microtransactions, which have not been successful with traditional payment methods. Micropayments can be used to improve retention, decrease customer acquisition costs, and increase the lifetime value of customers. By leveraging Google Cloud’s global network, Voltage can satisfy user needs faster, and the following benefits: Capability to serve a global audience across different regions, with initial operations in Iowa, Netherlands, and Singapore Deployments on a leading cloud with superior availability and networking The ability to effortlessly run a Bitcoin infrastructure close to existing workloads Google Cloud is leading the way in supporting cryptocurrencies like Bitcoin. It has shown a dedication to this new technology and is helping bring it to a global audience, while also being a leader in cloud-native technologies like Kubernetes that Voltage can leverage to easily scale its platform. By using Google Cloud, Voltage can satisfy the complex requirements that enterprise adoption requires.