How it works
- Your app signs the user in with Firebase Auth (Email/Password, Google Sign-In, Phone, or any other Firebase Auth provider).
- You configure the Portal SDK with a callback that returns a fresh Firebase ID token.
- During backup, the SDK encrypts the client backup share and stores the encryption key in the secure enclave, authenticated by the Firebase ID token.
- During recovery, the SDK retrieves the encryption key from the secure enclave using the same authentication, then decrypts the backup share to restore the wallet.
Security model
The secure enclave is Portal’s Trustless Backup Service (TBS) atbackup.web.portalhq.io. Every Portal SDK calls it directly from the user’s device. The only secret it stores is the encryption key for each client’s backup. It never stores key shares, encrypted backups, or Firebase tokens. Alongside the key it keeps the Portal client ID and a hash of the bound Firebase UID (see below).
The encryption key is a random 256-bit AES-GCM key generated on the device for each backup. Portal’s main API never receives the key, and the Trustless Backup Service never receives the encrypted share.
How requests are authorized
Every request to the Trustless Backup Service carries two credentials, and both must be valid:- The Portal client credential (Client API Key or Client Session Token) identifies the Portal client.
- The Firebase ID token identifies the user. The service verifies its signature against Google’s public keys, checks that it has not expired, and requires its issuer and audience to match the Firebase project ID you registered for the environment.
How the key is protected
- The Trustless Backup Service runs in AWS Nitro Enclaves, on infrastructure separate from Portal’s main API.
- TLS terminates inside the enclave.
- Stored keys are envelope-encrypted with AWS KMS, and the key policy only allows decryption from an attested enclave running Portal’s approved build.
Integration requirements
- Keep one Portal client per user. The key is bound to the Portal client. When a user recovers on a new device, authenticate as their existing client instead of creating a new one.
- Keep the Firebase UID stable. If a user signs in with a provider that creates a new Firebase user instead of linking to the existing account, recovery fails with
403. Use Firebase account linking for users with more than one sign-in provider. - Backing up again replaces the key. Each backup stores a new key for the client.
- Firebase backup keys cannot be deleted. The Trustless Backup Service has no delete operation.
- Register your Firebase project in every environment you use, including production.
Errors
Prerequisites
- A Firebase project with Firebase Authentication enabled.
- At least one sign-in provider configured in Firebase Auth (Email/Password, Google Sign-In, Apple Sign-In, etc.).
- Your Firebase project registered with Portal (see below).
Register your Firebase project with Portal
You must register your Firebase project with Portal so that the secure enclave can validate your users’ Firebase ID tokens.- Go to the Portal Dashboard.
- Navigate to Configuration > Firebase Auth.
- In the Firebase Backup Authentication Config section, enter your Firebase Project ID and save.
You can also register the JWT provider programmatically via the Custodian API:
Add Firebase to your app
- iOS
- Android
- Flutter
- Web
If you have not already set up Firebase in your iOS app, follow the Firebase iOS setup guide. At a minimum, you need to:
- Add your iOS app in the Firebase Console.
- Download the
GoogleService-Info.plistfile and add it to your Xcode project. - Add the
FirebaseAuthdependency via Swift Package Manager or CocoaPods. - Call
FirebaseApp.configure()in yourAppDelegateor app entry point.
Supported platforms
Firebase Auth Backup is currently available on:- iOS - See the iOS Back up a wallet guide
- Android - See the Android Back up a wallet guide
- Flutter - See the Flutter Back up a wallet guide
- React Native - See the React Native Back up a wallet guide
- Web - See the Web Back up a wallet guide