docs: add updated wallet security documentation

Author: ElasticBottle

apps/portal/src/app/connect/sidebar.tsx

@@ -102,7 +102,7 @@ export const sidebar: SideBar = {
             },
             {
               name: "Security",
-              href: `${ecosystemSlug}/security`,
+              href: `${walletSlug}/security`,
             },
             {
               name: "Get Started",

apps/portal/src/app/connect/wallet/security/assets/app-scoped.svg

@@ -0,0 +1,77 @@
+import AppScoped from "../assets/app-scoped.svg";
+import EmbedCreation from "../assets/embed-creation.svg";
+import { DocImage, Callout, createMetadata } from "@doc";
+
+export const metadata = createMetadata({
+	image: {
+		title: "In-App Wallet Security",
+		icon: "wallets",
+	},
+	title: "In-App Wallet Security",
+	description:
+		"Learn how thirdweb protects your user's private keys using Shamir's Secret Sharing algorithm",
+});
+
+# How it works
+
+## Wallet creation
+
+When a user signs into an application using their email or social logins for the first time, a wallet is generated on the user's device. The corresponding wallet key for this wallet is securely split into three shards using [Shamir's Secret Sharing](https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing) algorithm.
+
+1. **Shard A** is stored securely on the user's device. For web applications, this is stored on the browser, or for mobile apps, it is in a secure enclave.
+2. **Shard B** is encrypted and stored in [Amazon KMS](https://aws.amazon.com/kms/) using a key known to thirdweb. This process uses [hardware security modules](https://en.wikipedia.org/wiki/Hardware_security_module) (HSMs) to protect the confidentiality and integrity of keys. The encrypted string is stored in thirdweb's database.
+3. **Shard C** is encrypted by user authentication and stored in Amazon's KMS using hardware security modules (HSMs) to protect the confidentiality and integrity of keys. Despite the key stored on thirdweb's servers, thirdweb has no way of decrypting and accessing the key.
+
+<DocImage src={EmbedCreation} />
+
+## Recoverability
+
+In-App Wallets are non-custodial, and users can export their private key anytime. Users may recover their wallet from any device by authenticating or signing into an application to receive access to their wallet.
+Threshold secret-sharing cryptography is used to recreate the private key; two of three shards are required.
+If a user loses access to their authentication method (email, social login, or custom authentication), they cannot recover their wallet.
+
+<Callout variant='info'>
+
+thirdweb does not have the ability to access user accounts or reconstruct private keys.
+
+</Callout>
+
+## In-App Wallet Scope
+
+In-App Wallets are scoped to applications per API key. If users use the same email to sign in to a different application using In-App Wallets, the application will manage an entirely different wallet.
+
+### Benefits of single application scoped wallets
+
+- Each application has limited access only to wallets created through their application. It cannot manage wallets from other applications.
+- Users may only view tokens sent or purchased from your application.
+- To improve user experience, saved payment methods and KYC verification are only provided to thirdweb; applications cannot view this information.
+
+Users may view all their application-scoped In-App Wallets in a single view using the [My Wallets](https://ews.thirdweb.com/wallet) dashboard. Learn more about My Wallets.
+
+<DocImage src={AppScoped} />
+
+### Scalability
+
+We support up to 100 wallets generated/second by default and can support higher limits (up to 3,000 wallets generated/second) upon request. [Contact Sales](https://thirdweb.com/contact-us) for more information.
+
+### Security & privacy
+
+#### TLS Encryption
+
+To increase security and privacy, private keys or wallet "seed phrases" are never stored or sent over a network. TLS encryption is used in transit for internal and external communications with thirdweb's back-end and databases. TLS encryption is also required for third-party vendors.
+
+#### AES-256
+
+Data backups and storage are encrypted with AES-256.
+
+#### Threshold secret sharing
+
+Using threshold secret sharing, thirdweb cannot reconstruct a user's private key, thereby providing a non-custodial wallet. Additionally, a customer's assets are safe even if thirdweb or the application developer (you) is compromised. In a compromised situation, an attacker may only be able to access one of three shards, which is inadequate to reconstruct the wallet's private key.
+
+#### GDPR & CCPA
+
+thirdweb complies to GDPR and CCPA compliance frameworks and deletes customer data per request within the required timeframe of each standard (30 days for GDPR and 45 for CCPA).
+
+#### Audit and Bounty Program
+
+HackerOne has audited our in-app wallet private key security architecture, and there is an ongoing bounty program to ensure vulnerabilities are caught. [View the Letter of Attestation.](/pdfs/thirdweb_code_security_audit.pdf)

apps/portal/src/app/connect/wallet/security/assets/ecosystem-scoped.svg

@@ -0,0 +1,104 @@
+import { DocImage, Callout, createMetadata } from "@doc";
+import EnclaveWalletCreation from "./assets/enclave-wallet-creation.png";
+import AppScoped from "./assets/app-scoped.svg";
+import EcosystemScoped from "./assets/ecosystem-scoped.svg";
+
+export const metadata = createMetadata({
+	image: {
+		title: "In App wallet and Ecosystem Security",
+		icon: "wallets",
+	},
+	title: "thirdweb Wallet Security",
+	description:
+		"Learn how thirdweb protects your user's private keys across applications using nitro Enclaves",
+});
+
+# thirdweb Wallet Security
+
+If you are looking for the previous security documentation around the shamir secret sharing model, please refer to the [In-App Wallet Security](/connect/wallet/security/legacy) page.
+
+## Wallet Creation
+
+When a user signs into an application using their email or social logins for the first time, a wallet is generated within a secure enclave on the server after verifying the user's legitimacy. The enclave provides a trusted execution environment, ensuring the wallet creation process is isolated and protected from external interference.
+
+- The wallet and its corresponding private key are generated entirely within the enclave, never leaving its secure confines.
+- User authentication data is verified within the enclave, ensuring that only legitimate, authenticated users can initiate wallet creation.
+
+<DocImage src={EnclaveWalletCreation} className="max-w-96" />
+
+
+## Security Measures
+
+- The enclave's cryptographic properties ensure that even the server operators cannot access the contents or operations within the enclave.
+- The enclave provides a verifiable hash of the image of the code that is being run on the device, allowing anyone to verify the contents of the code.
+- The wallet's private key never exists in an unencrypted form outside of the enclave.
+- All sensitive operations, such as transaction signing, occur within the enclave, ensuring the wallet's security.
+
+## Wallet Usage
+
+### General Usage
+
+- When users interact with their wallet via the the enclave, all communications are encrypted and only the legitimate user can access their wallet.
+- All traffic is encrypted with TLS and HSTS. Services are run in private VPCs on AWS and accessible only from a single entry point via our Cloudflare DNS.
+- Applications can [link multiple authentication methods](/connect/in-app-wallet/guides/link-multiple-profiles) to the same wallet. Any of these methods can be used to authenticate into the users wallet.
+
+### Ecosystem Usage
+
+Ecosystem wallets are controlled by the ecosystem owner. Ecosystem owners are able to specify usage policies for their partners and developers which restricts what they can do with the wallet. Unlike the shamir secret sharing model, the enclave wallet model ensures that the private key is never reconstructed on the client. This ensures no-one can extract the private key from the client, including other developers in the ecosystem. Moreover, it also means that partners and developers must submit the request to the enclave which would be able to verify the request and block requests that are out of scope or denied by the ecosystem owner.  
+ 
+## Scopes
+
+
+### In App Wallets
+
+In-App Wallets are scoped to applications per Client ID. If users use the same email to sign in to a different application using In-App Wallets, the application will manage an entirely different wallet.
+
+#### Benefits of single application scoped wallets
+
+- Each application has limited access only to wallets created through their application. It cannot manage wallets from other applications.
+- Users may only view tokens sent or purchased from your application.
+- To improve user experience, saved payment methods and KYC verification are only provided to thirdweb; applications cannot view this information.
+
+<DocImage src={AppScoped} />
+
+### Ecosystem Wallets
+
+Ecosystem Wallets are scoped to the ecosystem. If users use the same email to sign in to a different application using the same ecosystem, they will get the same wallet.
+
+#### Benefits of ecosystem scoped wallets
+
+- Applications can now share assets across various applications. This is useful if you're a brand powering multiple application and want your partners to take advantage of network effects.
+- Application owner has full control over what happens within each application. This is useful if you're a brand that wants to ensure that all applications in your ecosystem are following the same rules.
+
+<DocImage src={EcosystemScoped} />
+
+
+## Recoverability
+
+- Users can export their private key at any time. 
+- Users may recover their wallet from any device by authenticating or signing into an application to receive access to their wallet.
+- Thirdweb wallets support four categories of authentication: socials, custom authentication, external wallets, and email / phone authentication. If a user ever loses access to their authentication method:
+
+  1.  **For socials and email / phone authentication,** users can utilize the recovery flow of their providers to regain access to their account.
+  2.  **In the case of custom authentication,** the developer managing their authentication flow will be able to re-instate the users account upon successful verification.
+  3.  Application providers **do not have direct access** to user accounts or private keys, as these remain secured within the enclave. The enclave's design ensures that only verified user requests can trigger wallet operations.
+
+- Users are able to link their authentication methods which will provide them multiple ways to access their account if they ever lose access to any one of their authentication method.
+
+## Security & privacy
+
+### TLS Encryption
+
+To increase security and privacy, private keys or wallet "seed phrases" are never stored or sent over a network. TLS encryption is used in transit for internal and external communications with thirdweb's back-end and databases. TLS encryption is also required for third-party vendors.
+
+### AES-256
+
+Data backups and storage are encrypted with AES-256.
+
+### GDPR & CCPA
+
+thirdweb complies to GDPR and CCPA compliance frameworks and deletes customer data per request within the required timeframe of each standard (30 days for GDPR and 45 for CCPA).
+
+### Audit and Bounty Program
+
+Halborn has audited our enclave wallet security architecture which we'll be releasing shortly, and there is an ongoing bounty program to ensure vulnerabilities are caught. [View the Letter of Attestation.](/pdfs/thirdweb_code_security_audit.pdf)