Developing wallets that don't expose keys and security pass phrases

September 27th, 2022

1. Introduction

Almost all the wallets out there require public and private keys. More so, the mnemonic phrases or 12 seed phrases are prevalent for password recovery. This is prone to spear phishing cyber attacks; it is hard to maintain, expensive and it’s a big hassle for the users. A decentralized security model could plug this hole and solve most of the cyber or web3 security problems. Currently, the protocols use a key based system like public/private key pair called public key infrastructure(PKI).

Fig 1.0 Client-server encryption handshake

We would like to create a wire frame that could properly and effectively show the current state of the protocols and authentication mechanisms. To this end, we publish this article to improve on them.

2. The data flow diagram for wallet use case

We are quite familiar with the flow for a sufficiently decentralized social network. - ‘Far.caster’, which is a WEB 3.0 solution on beta testing. Fig 2.0 presents possible wallet interaction architecture. The idea behind the diagram is to show what is obtainable today. However, WEB 3.0 relies on wallet for a lot of its networking and financial services. Identification could be carried along this way to quickly prove identity profiles.

Distributed node architecture

Managed hosting
Self-hosting

3. Use AWS AMI/Docker image to build the wallet key less security

Server or Node setup

AWS AMI quick start guide

Docker images

APIs from ECSMID V 1.0.0 SDK

4. Secure the wallet with LokDon ECSMID V 1.0.0

In this article we will present a new direction in securing the wallet using proprietary protocols and advanced authentication in the framework of security of information by encrypted verification, validation, and evaluation. - CyberLocks are identity components for securing information by encrypted, verification, validation, and evaluation. They are powered by ECSMID V 1.0.0 (SDK, JWUT and APIs ) and can support many clients just like any large application SDK. Instead of using the private keys, we established legitimate and secure communication objects to conveniently enable exchange between two entities. If a protocol is good enough to establish the handshake without exposing any private key, then this is a solution worth exploring. The key is encrypted and decrypted on-demand.

Sender (S): One initiating transaction e.g text message, smart contract, and balance.

Verifier: One who verifies the network or communication exchange object sent forth to them.

Provenance: Attributes of verifiable credentials arranged for communication exchange object.

Proof: Is the message and provenance as a function or proof object in the overall process.

Intermediate representation (IR): The encrypted version of the message and the provenance.

Prove: The process of proving the proof as an intermediate representation.

Zero knowledge proof ( ZKP): This is a process where verifier shows insight (in our case identification) without really given out more than necessary information to prove that they know a value without know the function form which the value is derived. Let say a function f(x) =x2 – 64 is the proof, we expect the verifier to submit x=8 without the knowledge of f(x).

Identification: In this process the verifier can not be given access without disclosing who they are without divulging more than the relevant information. This a complementary part of the Zero-knowledge prove and identification ( ZKPI).

Receiver (R ): One responds to transaction e.g text message, smart contract and balance.

We created this protocol with a different flow diagram to show an alternative approach that relies less on keys moving from point A (Sender) to point B (Receiver). This will capture the encryption, attributes from verifiable credentials to build profiles called universal wallet address (UWA): UWA qualified as data nucleus aggregator (DNA). These profiles could be held locally or externally as digital data nucleic authority (DDNA). This arrangement will allow an individual to carry their social profile, and their digital identity from one place to another.

The crux of the matter is that none could obtain authorization to access any data without authentication via zero-knowledge proof of identification (ZKPI). Ultimately this flow is basically for access to be granted. Senders/receivers will have the capability to encrypt all data autonomously using quantum resistant cryptography. The protocol is inclusive and changes human readable information to intermediate representation sufficient to stand as provenance which must be proven by a verifier following a zero-knowledge proof of identification.

DDNA will serve the purpose of a simple smart contract registry (SCR) - [4]. The difference here is that it does contain many DNAs (DNA is an instrument derived from username, address and PIN following SIEVVE) of more than one entity. Simply put, DDNA holds disparate DNAs. Some examples include biometric, PIN, location, driver license number etc., from different entities covering factors like what you are, what you have, what you know and where you are known as the details of advanced authentication. Once a user gives you one of these attributes used to create the DNA: It is easier to figure out the communications exchange object for that user.

Table 1.0 Attributes of verifiable credentials

You can easily go to DDNA or validation list below to find out the communication exchange object needed to communicate with an entity. You will have to query with the proper attribute on the DDNA explorer interface. If successful you should obtain the communication exchange object if they have one.

Preambles:

There will be an update introducing an inclusive mechanism which mimics the silent password of 8 chars used in LokDonX. – Originally, we got the 8 chars from 4-digit PIN mechanism.

*We can add the 4 characters from the public UWA as an update to what we already have. They could be chosen randomly as a set or as 4 singletons to be infused in all communications to secure the message for sender and any recipient. – Same thing we have done with MPIN in LokDonX.

*There is also a set of 11 character derived as a subset from the UWA stripped M3UWA. We must make sure upon decrypting M3UWA to M2UWA that the position of characters matches what the local device has in M2UWA.

Once UWA is successfully created. The encryption of the collected attributes will follow:

Using Universal wallet address (UWA) to solve PKI insecurity problems

Configure Wallet Address-:

PLAIN UWA: LCN77**7838%993%^849938jd*()))abu,!\]}jhjdfkg

Mode 1. LCNÔăĤ³6¤=oÍðRĥÃ2úWĽÜ±AįĮ±Âªh(âĞĎĀ$Ď<V*ĚħAïþĶĆÝ unused

Mode 2. LCN}ŀĐĦxĸ/¥@īòĞv¶ĒVSĎīĢ4ðĩ'@ğď¤BĒĈ´ļĜ´#+PėöĬĂm7Ë;

Mode 3. LCNüÚ'Ď!İ§ÍïėĄĈ¿ĸYzĬÃ.mÝþĩÀ3øñÝñÿOëÕ{ąSr"> ī÷²HàÏ6j public

We will go over the three (3) major scenarios in which you can apply this solution.

SCENARIO 1

The first principles flow establishes the use of origin identification technology or secure true digital identification (physical and virtual) with respect to advanced authentication. However, scenario one assumes that UWA is created already. You can read our whitepaper for more details on UWA – [2].

When sender A send the message to the receiver B: The steps are as follows

Step 1. A encrypts message with public UWA locally

a. Encrypts the message with infusion or randomly established 4 characters: A part of Receiver’ M3UWA. This one is a part of the modulo addition (OR) or modulo exclusive or type (XOR).

b. The message is thereafter concatenated with 11 characters more from the M3UWA. This case is to establish proof with zero knowledge and trigger authentication.

Step 2. Message from A is sent over the internet to B following security of information by encrypted verification, validation, and evaluation (SIEVVE) mechanism. Which is comprised of many protocols.

Step 3. B the receiver upon receiving the information is challenged to zero-knowledge proof. In other words, s/he identifies self by presenting a value without revealing any underlying information.

Step 4. B clears the zero-knowledge proof, an ensemble of SIEVVE. Access is granted to read the message. The system is sound.

Step 5. B fails the zero-knowledge proof, an ensemble of SIEVVE. Access is denied the system is correct.

Step 6. The receiver (B) could read the message from A (sender or sending wallet address) as the case may be.

a. Transactional

i. Text messages

ii. Balances

iii. Contracts

Step 7. A will also go through the zero-knowledge proof once B sends a response to them. With a completed cycle we know both the sender (A) and the receiver (B)

How can we apply this to already made ecosystem like cryptocurrency and Web 3.0 wallets?

Configure wallet address-:

PLAIN BTC WA: 1Awyd1QWR5gcfrn1UmL8dUBj2H1eVKtQhg [given to the public]

Mode 1. Ĩd%J©Ģ_ĸÌĮĴ#ġúęJn{(ĒgĽóNĝ4NöĄ²'y»ĖfH unused

Mode 2. ĘĐÙ©Ñ+\"4Ò÷ĺĠěÂ4|ÏÇÙ$Lxö%RĂK]VWEĵĩ6£,Øõ

Mode 3. T[íqGĄ0BrIĩ =ĳēxKÌûĢĵ.ÇîFĤ×+$ĭč¸èÝĆîÌþĝ§ public

Scenario 2

We know that new users are having problems of securing keys. This does not preclude 12 seed phrases to protect the wallet. The newbies are very prone to phishing attacks. This is costing the companies millions of dollars.

Use sender/receiver M3BTCWA random 4 characters to encrypt (modulo addition, like silent password):

a. The private key of the wallet

b. Seed phrases

Since there is not key to move around here. Relying on the design of the ecosystem this will be an added layer of security which creates a useless string or gibberish following phishing attacks

Map and mask sender/receiver M3BTCPK (assuming private key is already created and in use)

i. Configure the private key

PLAIN BTC PRIVATE Key: DA46B559F21B3E955BB1925C964AC5C3B3D72FE1BF37476A104B0E7396027B6

Mode 1. ěýxæå¸ÜLÇeýī%ùþurÅĄ5Ä÷{êĴ³Ĉhzx (ïtåëÛV1ĥİÐĕvĥB\āpb¤ÈĄħĴZļ½lěČ/èkñĂ unused

Mode 2. §2ĥĎb~Ġĸê!¶öÿÁ:×ĵ@oæċĩ²Ĳ½Ħ<ļ®¨ėeÔôĀý}ýèùÆÓ¸ı´ľPsW+(|äZēpăJüěRĖÃéĦ×

Mode 3. sĬĝ6CÁĬĊ9Ħª=WĀĪH+Lx:Ė=æĩæsMô)´,Įçĝ»ªQìĽKl!îOĵsÉñĝOOHÚ´B&CĨcĮiÈDďÎµĜê public

Go to the first principles flow.

Step 1. A encrypts message with a part of the public UWA locally

a. Encrypts the message with infusion or randomly established 4 characters: A part of Receiver’ M3BTCWA. This one is a part of the modulo addition (OR) or modulo exclusive or type (XOR).

b. The message is thereafter concatenated with 11 characters more from the M3BTCWA. This case is to establish proof with zero knowledge and trigger authentication.

Step 2. Message from A is sent over the internet to B following security of information by encrypted verification, validation, and evaluation (SIEVVE) mechanism. Which is comprised of many protocols.

Step 3. B the receiver upon receiving the information is challenged to zero-knowledge proof. In other words, s/he identifies self by presenting a value without revealing any underlying information.

Step 4. B clears the zero-knowledge proof, an ensemble of SIEVVE. Access is granted to read the message. The system is sound.

Step 5. B fails the zero-knowledge proof, an ensemble of SIEVVE. Access is denied the system is correct.

Step 6. The receiver (B) could read the message from A (sender or sending wallet address) as the case may be.

a. Transactional

i. Text messages

ii. Balances

iii. Contracts

Step 7. A will also go through the zero-knowledge proof once B sends a response to them. With a completed cycle we know both the sender (A) and the receiver (B)

How can we extend this to Password Recovery (Reference is to the seed phrased)?

Configure Wallet Address-:

PLAIN BTC WA: 1Awyd1QWR5gcfrn1UmL8dUBj2H1eVKtQhg [given to the public]

Mode 1. Ĩd%J©Ģ_ĸÌĮĴ#ġúęJn{(ĒgĽóNĝ4NöĄ²'y»ĖfH unused

Mode 2. ĘĐÙ©Ñ+\"4Ò÷ĺĠěÂ4|ÏÇÙ$Lxö%RĂK]VWEĵĩ6£,Øõ

Mode 3. T[íqGĄ0BrIĩ =ĳēxKÌûĢĵ.ÇîFĤ×+$ĭč¸èÝĆîÌþĝ§ public

SCENARIO 3

Step 1. A encrypts OTP with a part of the public UWA locally

a. Encrypts the message with infusion or randomly established 4 characters: A part of Receiver’ M3BTCWA. This one is a part of the modulo addition (OR) or modulo exclusive or type (XOR).

b. The message is thereafter concatenated with 11 characters more from the M3BTCWA. This case is to establish proof with zero knowledge and trigger authentication.

Step 2. Message (Sending encrypted OTP text message to primary authentication device

from A is sent over the internet to B following security of information by encrypted verification, validation, and evaluation (SIEVVE) mechanism. Which is comprised of many protocols.

Step 3. The receiver B, upon receiving the information is challenged to zero-knowledge proof. In other words, s/he identifies self by presenting a value without revealing any underlying information.

Step 4. B clears the zero-knowledge proof, an ensemble of SIEVVE. Access is granted to read the message. The system is sound.

Step 5. B fails the zero-knowledge proof, an ensemble of SIEVVE. Access is denied the system is correct.

Step 6. The receiver (B) could read the message from A (sender or sending wallet address) as the case may be.

a. Transactional

i. Text messages

ii. Balances

iii. Contracts

Step 7. A will also go through the zero-knowledge proof once B sends a response to them. With a completed cycle we know both the sender (A) and the receiver (B)

Sending a representation of the seed phrase or mnemonic in the form of an encrypted OTP (6–12-character strings) will remove the targeted attacks on the see phrases.

Note: User are constantly advised and reminded to back up the application locally or to a managed cloud service (individual or enterprise).

Why must we use key less E2EE?

When we look at the main attack on cyber (blockchain, NFT, Metaverse and Web 3 projects) security. We see the astronomical increase in financial losses. We are aware the two major attacks vectors on the 2022 list:

1. Flash loan attacks

2. Spear Phishing attacks

Both attacks will take advantage of access, manipulation and/or abuse of public and private key pairs amongst many other things. – [5]. They cost the industry over $2B.

There is more than one social impact aspect here: Privacy preservation and information security. These two will bring about data autonomy and passive income, absent third party data brokerage. Since data is destiny in the digital world. Those who can control their information will control their future.

There is not enough time and space to present the code snippets in this article: We will do that in a follow up article. Show codes here=> This is a reminder for continuation.

Conclusion

We recognized how important it is to decentralize security by introducing autonomy and control. This snowballs into possible financial gains for social network builders and the content creators. This could be good for everyone online. We lean towards product decentralization, in fact peer to peer (P2P) network solutions are sparks to ignite the on-chain security revolution without undermining the off-chain solutions. Our security architecture is key less with unique origin identifiers, secure, private, and shareable to the public. Individuals could affect these factors in a practical way. -It is sufficiently decentralized and could be used for both centralized and decentralized environments. Every digital asset cannot be on the chain. That is because things on the chain are immutable, you cannot change them. However, messaging (SMS and Web message) requires editing from time to time. One must be dynamic to account for the changing demand from, data flows, data stores, entities (critical assets) and processes. Assets could effectively be secure by using a key less infrastructure whether it is on-chain or off-chain. For solutions requiring editing (qualitative and quantitative) updates, corporations might not need them on the chain since immutability does not align with frequent changes. In any case corporations can have full chain of custody with on-demand key less, and end-to-end encryption(E2EE). In fact, large application builders can use this approach to protect privacy as well as secure data in the expanding cyber space, including Blockchain, NFT, Metaverse, and WEB 3.0. Of course WEB 3.0 is a smelting pot for the aforementioned applications.

Thanks to Nahom Wosenu Will Lewis (SuperOwn), Dan Romero (FarCaster), Alexander Chopin, Ukarsh Jaiswal