Magic’s goal is to meet companies wherever they are on the path to Web3 adoption—from exploring authentication options to fully integrating with a blockchain, Magic provides solutions that developers and enterprises alike can trust. Our mission to onboard the next billion users to Web3 is not just a catchphrase, it’s a foundation that affects how we address security at every aspect of the user journey.
Magic doesn’t use passwords; there’s another option.
Passwords are only one (obsolete) way to handle authentication. Magic utilizes one-time passcodes to grant access. Delivered through email, these passcodes are time-bound tokens that enable authentication without having to store and maintain passwords. Optionally, Magic also partners with social providers to leverage cross-platform authentication for our products.
Phishing is an ever-present threat on the internet
Since the creation of the internet, hackers have leveraged phishing to direct victims to authentic-looking pages to attack them or steal their credentials. Hackers can craft incredibly realistic pages, utilize social engineering to entice victims to connect, and capture credentials for later use in direct attacks or credential-stuffing attacks elsewhere on the internet.
Magic’s approach to authentication makes phishing much more difficult. Because Magic uses time-bound tokens, any credentials captured from successful phishing attacks have the same limited shelf life. Magic’s innovative approach to device registration for authentication, for customers who wish to take advantage of it, dramatically increases the difficulty of phishing attempts.
Once an end-user uses their time-bound token to establish a session with Magic, Magic generates a key pair based on the Ethereum blockchain. The public key acts as an identifier for the user. Leveraging elliptic curve cryptography, the private key is used to generate a verifiable proof of identification and authorization from a claim. The proof is then sent to the developer application servers where data in the claim can be recovered, and the authenticity of the request can be ensured. Authentication and authorization are achieved without requiring user passwords. The claim format is an adaptation of the W3C Decentralized Identifiers (DID) protocol. Learn More about Magic DID’s here.
With this public–private key-pair approach, it is critical to ensure that users’ private keys are properly secured. That’s what our patent-pending TEE Key Management System (TKMS) is designed for. Building on the success of our earlier DKMS, which has safeguarded millions of private keys for thousands of companies, TKMS takes key security to the next level. By leveraging distributed key shards, Trusted Execution Environments (TEEs), and AWS KMS, Magic delivers private key management that is secure, scalable, and resilient, all backed by best-in-class cryptography standards.
Magic provides infrastructure that manages sharded private keys instead of a single encrypted key. The key is split using Shamir’s Secret Sharing (SSS) across Magic, or optionally the Dapp/Developer depending on the security requirements. Each shard is additionally encrypted and secured in Trusted Execution Environments (TEEs) with AWS KMS, preventing human access to key material.When an operation like signing is requested, shards are retrieved and securely recombined inside the TEE, never leaving hardware isolation. The private key only exists ephemerally in the TEE enclave’s protected memory space for the operation, and only the signed result is returned.
The TEE Key Management System requires an additional authentication layer beyond hardware-level protection. This layer provides both user authentication and authorization, working in combination with TEE attestation and external shards to ensure maximum security.How the authentication layer works:The system generates and manages secure secrets stored in cloud infrastructure, with each user’s identity cryptographically bound to their wallet through secure hashing. Every API request to the TEE service must include proper authentication credentials, which the backend service validates before processing requests. The secure enclave uses these credentials for both authentication and key decryption, ensuring that only authenticated users can access their specific private keys.This authentication layer provides identity-based access control where each user can only access their own wallets and private keys. This multi-layer protection works in combination with KMS attestation and external shards to create a comprehensive security framework that prevents unauthorized access even if the TEE system is compromised.
