❔FAQ

Is Daisen´s system better than the usual creation of a Non-custodial?

Yes, because it is more straightforward. Most crypto users (98%) do not use DeFi and are unfamiliar with Non-custodial wallets. The success of Daisen depends (among others) on a simpler onboarding to achieve a CEX-like experience in a fully DeFi and Non-custodial protocol. That is why we have implemented a frictionless onboarding in which, although the user does not know it, he is creating a wallet and he (and no one else) is guarding his assets.

Why we don't use a password?

Most applications today are built with username/email/phone + password security model, which is obsolete for many reasons:

Password leaks are prevalent

Type your email in HaveIBeenPwned and realize that your sensitive data and passwords have likely been compromised in many high-profile breaches impacting companies like Equifax, Dropbox, Adobe, Kickstarter, LinkedIn, Tumblr, and so many more. If there exists a database with passwords, it’s only a matter of time before they get stolen.

Even hashed+salted passwords are insecure

Once a database of hashed passwords is stolen, hackers can direct immense distributed computing resources at that database of passwords, utilizing parallel GPUs or botnets with hundreds of thousands of nodes to attempt hundreds of billions of password combinations per second in hopes of recovering plaintext identifier+password pairs.

Once attackers discover a password that hashes to the same hash as the one stored in the database, they’ll take that identifier+password pair and try it on other applications like bank accounts. In many cases, a salted+hashed password database can give up another valid identifier+password couple around every minute. This results in about half a million leaked passwords per year — doubling every few years.

For companies using passwords as secrets to encrypt sensitive data, it's very much like symmetric encryption where the encryption key is a weak password that can be easily cracked by brute force.

User sessions often get hijacked

User sessions are often hijacked after successful authentication, allowing attackers to exploit that user’s application resources. In order to prevent that, you’d need to re-authenticate the user with every request, and this would create an extremely cumbersome user experience if users have to type in their password every single time.

Eric Elliott wrote a great article that covered many of these issues.

Managing passwords increases cost and liability

81% of all breaches are due to passwords, and 59% of people reuse their passwords everywhere [Source], and breaches are costing companies on average $240k per 1k records [Source].

Over 50% of all support tickets are password-related (usually forgotten passwords). Each ticket costs companies around $70 - handling 10 tickets daily will cost an organization close to $128k annually [Source].

Does Daisen use any public or private key pairs of users as a form of authentication?

Absolutely not. Instead of SSH key pairs, each end user of the application generates a key pair based on Ethereum's decentralized blockchain network. The public key acts as an identifier for the user. Leveraging elliptic curve cryptography, the private key is used to generate verifiable proof of identification and authorization of a claim. The proof is then sent to the developer's application servers, where the claim data can be retrieved and the authenticity of the request can be guaranteed. Voila! Authentication and authorization are achieved without requiring user passwords. The claim format is an adaptation of the W3C Decentralized Identifiers (DID) protocol [Learn More].

What is Delegated Key Management?

The Delegated Key Management (pat. pending. USPTO 62/904689). Which has been securing tens of thousands of user private keys for thousands of blockchain companies, it is a non-custodial key management model through the hardware security modules. The system design prevents the access of an attacker, Daisen or any actor involved or not in the protocol to the keys.

How does DKM work?

Thanks to hardware security modules (HSMs) provided by the Amazon Web Services Key Management Service (AWS KMS). Dedicated user master keys are stored in the HSMs, which are generated using AES-256 with 384 bits of entropy. The master keys never leave the hardware, as they are intended to be locked inside and cannot be exported, where all encryption and decryption operations occur within the hardware itself. HSMs are much like popular FIDO devices such as YubiKeys or hardware-based wallets for cryptocurrency storage such as Trezor or Ledger, but instead, they are in the cloud, heavily protected by AWS data centers.

Users' private keys are encrypted by these hardware-based user master keys, which means that attackers need to gain access to this hardware in order to obtain the keys, and are forced to stay within the infrastructure, which is able to detect, impede and monitor the attackers' progress to prevent and mitigate any damage.

Is it Non-custodial?

Absolutely yes. The delegated key management architecture outsources critical encryption and decryption operations to a trusted AWS KMS and AWS Cognito, bypassing our backend entirely. In this way, we can remain non-custodial (standard of trust among cryptography communities) as we will never "see" users' private keys and therefore improve security and user trust.

Is the flow of user data to AWS secure?

In order for users to access their HSMs, they authenticate with relayer auth. Upon successful authentication, users receive a time-limited access token, which is exchanged for scoping credentials and, in turn, allows the customer to interact with AWS directly. The scoping credentials exclusively allow users to call AWS to access their master keys stored in the HSM for encryption and decryption. This mechanism completely bypasses our backend and we cannot spoof or intercept the scoped credentials because they are generated by transactions exclusively between customers and AWS. Both access tokens and scoped credentials are dynamically created by AWS, with audit trails and TTLs enabled.

When a user logs in, a public/private key pair is generated client-side for the user within an iframe, inaccessible to the embedded application. The keys are generated with a 256-bit entropy cryptographic pseudorandom. Once generated, the key is encrypted by Delegated Key Management, where we never see the raw private keys anywhere in the flow. After encrypting the keys with the HSM, the encrypted key is stored in the client-side iframe, as well as loaded into the authentication relay for redundancy, in case the client-side encrypted key is accidentally deleted. To ensure that no one can decrypt the encrypted key for redundancy, we have removed the permission to decrypt it with our KMS instances.

When users authenticate again, the encrypted private key is downloaded to the client. Users can then decrypt the encrypted private key directly with AWS KMS through Cognito.

What if I get phished or my email is hacked?

Phishing attacks are an ongoing problem that exists in our industry today. However, this does not mean we are satisfied with the status quo and are actively working to mitigate it. We have minimized attack vectors significantly by moving to passwords - no credentials are passed! Compared to traditional password-based solutions, we eliminate the case where users can be phished to compromise account information.

In addition, if a link email is lost or stolen (or even somehow compromised in transit), the user's account is safe! The token included in the email link only has the privilege of verifying a login request from the device and/or browsing context that initiated the request. An attacker would need physical access to the user's device and unencrypted email inbox to be malicious.