WO2020051710A1

WO2020051710A1 - System and process for managing digitized security tokens

Info

Publication number: WO2020051710A1
Application number: PCT/CA2019/051297
Authority: WO
Inventors: Jay JOE; Seil Kim
Original assignee: Joe Jay; Seil Kim
Priority date: 2018-09-12
Filing date: 2019-09-12
Publication date: 2020-03-19

Abstract

A system and process for managing digital security tokens that involve an identification blockchain layer, a security token blockchain layer, and a trade history blockchain layer. The identification blockchain layer storing records of user identifiers and authentication keys. The security token blockchain layer storing records of digital security tokens indicating digital security token identifiers, states and ownership data. The trade history blockchain layer storing records of verified transaction data. The identification blockchain layer receiving a recovery request; the security token blockchain layer retrieving a record of a digital security token identifier using a user identifier, updating data indicating a state of the digital security token to inactive, issuing a new digital security token having a new digital security token identifier; and the trade history blockchain layer updating a record for a transaction data with the new digital security token.

Description

SYSTEM AND PROCESS FOR MANAGING DIGITIZED SECURITY TOKENS

CROSS REFERENCE

[0001] This application is a non-provisional of, and claims all benefit, including priority to, U.S. Application No. 62/730224, entitled “SYSTEM AND PROCESS FOR DIGITIZED SECURITY TOKENS HAVING UTILITY FEATURES”, filed on 12-Sep-2018, incorporated herein by reference in its entirety.

FIELD

[0002] The present disclosure generally relates to the field of distributed ledgers and blockchains, and more specifically, to a platform for digitized security tokens.

INTRODUCTION

[0003] A blockchain is a collection of records or blocks linked by cryptographic data. A block of the blockchain cannot be altered without alteration of subsequent blocks which can provide verification and authentication. A distributed ledger is a consensus of replicated, shared, and synchronized digital data distributed across different entities. There is no central administrator or centralized data storage, for example.

[0004] An example of a distributed ledger can be a blockchain system. A digitized or digital token is an object that represents another physical or virtual object. An example digital token is a utility token which can provide a form of utility for a good or service. Another example digital token is a security token which can represent an external, tradable asset. A security token can be linked to a security of a company and can represent equity of the company, for example.

SUMMARY

[0005] Embodiments described herein relate to using a distributed ledger or blockchain based platform for digitized security tokens (DST) having utility features. Computing systems, computing devices, methods, computer program products, and non-transitory computer readable media storing machine-interpretable instructions are provided, in accordance with some embodiments.

[0006] A challenge with blockchain data records arises due to the decentralized nature of the blockchain and the corresponding distributed ledgers that stores and propagates sequential transaction records. A block on a blockchain can be configured to require a private key corresponding to a public key of a record stored on the distributed ledger that is required for conducting a transaction against the corresponding record. When a user provides the private key (e.g., through a user interface, a command line interpreter, or a digital wallet), the transaction can be recorded on the distributed ledger and then propagated more widely to other distributed ledgers. However, it is possible for the user to lose the private key (e.g., as a file stored on a computer and the computer is lost or the file is accidentally deleted). Without the private key, it may be difficult or impossible to modify or access the record stored thereon the distributed ledger. This is especially problematic where the record is associated with a utility token or has a tradeable value associated with it, as access to funds or functionality is lost, as the private key is needed to cryptographically sign transactions.

[0007] Coordinated recovery of the private key is a useful feature, and according to various embodiments, an improved computing platform system adapted to aid in recovery in the event of a lost key. An encryption based approach is utilized by the computing system to establish, in some embodiments, an authentication key generated during the encryption of a private key is provided that can be split into multiple key fragments or pieces. A subset of the fragments can be required to sign transactions, and in the event of a loss of a private key, a new public/private key pair can be established using the subset of key fragments.

[0008] As described herein in some embodiments, the fragments can be stored at different computing systems and released only after verification and/or validation of identity credentials are adduced (e.g., based on a KYC identifier data value and/or a KYC/AML state). The fragmented key may be established, for example, through the use of a smart contract functionality including executable code that can be invoked to cause signing of the blockchain data record only with the subset of key fragments.

[0009] In accordance with an aspect, there is provided a system for digital security tokens. The system has a server or network of servers having non-transitory computer readable storage medium with executable instructions for causing one or more processors to configure: an identification blockchain for receiving a user identifier and a password, generating an authentication key generated using the password, and storing a block indicating the user identifier and corresponding KYC identifier; a security token blockchain for receiving ownership data indicating a digital security token, a hash for the digital security token, and the user identifier, transmitting token status and traceability information and storing a block for the ownership data and the digital security’s smart contract and status data; and a trade history blockchain for receiving a transaction request from a security exchange, the transaction request linked to transaction data indicating the corresponding digital security token; the hash for the digital security token, buyer, seller, and data, wherein the buyer or the seller is linked to the user identifier, and storing a block for the transaction data upon verification using a smart contract. Each blockchain can be considered a computing layer established using physical computing devices (e.g., computing nodes) storing distributed ledgers which maintain and propagate transaction records across the physical computing devices such that the transaction records across the distributed ledgers are updated. Propagation and block validation rules control whether blocks are accepted for addition to the distributed ledgers.

[0010] In some embodiments, the buyer is linked to the user identifier and the seller is linked to another user identifier, wherein the security token blockchain layer can process an ownership transaction request indicating the other user identifier, the security token blockchain layer providing verification of the ownership status of the digital security token attached to the user identifier, verification of the active status of the digital security token, execution of smart contract code to enable utility features of the digital security token, the hash for the digital security token, the user identifier linked to the identification blockchain layer providing login authentication, signing of transactions, verification of the active KYC/AML status associated with the user identifier, verification of transaction eligibility between the buyer and seller against a whitelist, the user identifier linked to the trade history blockchain layer storing a record of all transactions related to the digital security token, and linked back to the security token blockchain layer to update the status of the digital security token upon change of ownership.

[0011] In some embodiments, the digital security token is a token linked to a digitized image of an original security in paper form with cryptographic hash to provide verification of authenticity and integrity.

[0012] In some embodiments, the digital security token is a token linked to electronic data stipulated on an original security with cryptographic hash to provide verification of authenticity and integrity.

[0013] In some embodiments, the authentication key is an encrypted encapsulation of the private key linked to a user identifier and password. The private key itself might not be stored anywhere in the system. In some embodiments, the authentication key is an instance and is continuously scrambled using a physical random number generator. The private key can be retrieved by decryption of the authentication key. [0014] In some embodiments, the identification blockchain layer stores a KYC identifier linked to a user identifier such that no personal information is stored throughout the entire system. The KYC identifier can be referenced to external KYC/AML data stored outside of the system by 3^rd parties such as KYC providers and exchanges.

[0015] In various further aspects, the disclosure provides corresponding systems and devices, and logic structures such as machine-executable coded instruction sets for implementing such systems, devices, and methods.

[0016] In this respect, before explaining at least one embodiment in detail, it is to be understood that the embodiments are not limited in application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.

[0017] Many further features and combinations thereof concerning embodiments described herein will appear to those skilled in the art following a reading of the instant disclosure.

DESCRIPTION OF THE FIGURES

[0018] Figure 1 is a diagram of a security token platform for the creation of security tokens, according to some embodiments.

[0019] Figure 2 is a diagram of components of a blockchain system, according to some embodiments.

[0020] Figure 3 is a diagram of components of a blockchain system, according to some embodiments.

[0021] Figure 4 is a diagram of a blockchain system interacting with a security exchange, according to some embodiments.

[0022] Figure 5 is a diagram of a blockchain system interacting with a security exchange, according to some embodiments.

[0023] Figure 6 is a block schematic diagram of blockchain systems, according to some embodiments. [0024] Figure 7 is a diagram of a process workflow for a method for digitized security tokens using blockchain systems, according to some embodiments.

[0025] Figure 8 is a diagram of blockchain systems, according to some embodiments.

[0026] Figure 9 is a diagram of a system for generating and storing secure keys, according to some embodiments.

[0027] Figure 10 is a diagram of an authentication key generation process, according to some embodiments.

[0028] Figure 11 is a diagram of a digitized security token (DST) transaction process, according to some embodiments.

[0029] Figure 12 is a diagram of a DST retrieval process, according to some embodiments.

DETAILED DESCRIPTION

[0030] Embodiments of methods, systems, and apparatus are described through reference to the drawings.

[0031] Embodiments described herein relate to using a distributed ledger or blockchain based platform for digitized security tokens having code to enable utility features. A digitized or digital token is an object that represents another physical or virtual object. An example digital token is a utility token which can provide a form of utility for a good or service.

[0032] Another example digital token is a security token which can represent an external, tradable asset. A security token can be linked to a security of a company (issuing entity) and can represent equity of the company, for example. The digitized security token can be a security or share in the issuing entity. The digital security token can be a digitized version of a traditional security with cryptocurrency features to enable transactions and other functions/features. The digitized security token can have utility token features. For example, embodiments described herein can involve issuance of a deed from a business trust. Under law, the deed of trust may be considered a security. The deed can also be linked to contractual terms and features that can be codified as smart contracts. The digitized token can integrate a securitized token with smart contract code. Utility token features can be codified in the smart contract. [0033] Cryptocurrencies are an example application of blockchain technology. They can use blockchain technology to document and transfer digital tokens. A second application level is smart property where tokens represent other goods. They may have features like electronic vouchers (so-called utility tokens) or securities (so-called security tokens.) This can link the value of such tokens to the underlying asset. A third application level consists of smart contracts where tokens not only represent simple assets or rights. In addition, a blockchain hosts the decentralized and automatic execution of computer applications and contracts.

[0034] A challenge with blockchain data records arises due to the decentralized nature of the blockchain and the corresponding distributed ledgers that stores and propagates sequential transaction records. A block on a blockchain can be configured to require a private key corresponding to a public key of a record stored on the distributed ledger that is required for conducting a transaction against the corresponding record. When a user provides the private key (e.g., through a user interface, a command line interpreter, or a digital wallet), the transaction can be recorded on the distributed ledger and then propagated more widely to other distributed ledgers. However, it is possible for the user to lose the private key (e.g., as a file stored on a computer and the computer is lost or the file is accidentally deleted). Without the private key, it may be difficult or impossible to modify or access the record stored thereon the distributed ledger. This is especially problematic where the record is associated with a utility token or has a tradeable value associated with it, as access to funds or functionality is lost, as the private key is needed to cryptographically sign transactions.

[0035] If a digital token derives its value from an external, tradable asset, it can be classified as a security token and becomes subject to securities regulations, for example. Failure to abide by these regulations could result in costly penalties and may stall or eliminate a project. However, if regulatory obligations are met, the security token classification creates the potential for a wide variety of applications, an example of which is the ability to issue tokens that represent shares of company stock. The security token, which can be transferred across the network and traded on cryptocurrency exchanges or security trading platform, can serve a multitude of different functions, while granting holders access to a service that entitles them to company dividends.

[0036] A digital security holder can receive profits, income, or other payments or returns from the issuing entity. The digital security holder can benefit from the expected increase in value of digital security. The digital security holder can have the right to a poll at any general meeting of the holders. [0037] Embodiments described herein relate to a platform for digitized or digital tokens with security compliance features. The digital token can be referred to as a Digitized Security Token (DST). A digital token can be issued by the entity established in the country under security law. The platform can enable the issuing entity to be registered with the relevant regulatory body and ensure the issuing entity complies with regulatory requirements. The platform can integrate with alternative trading systems, trade exchanges, and digital wallet applications. The platform can provide custodianship of the tokens, lifecycle traceability, lost key process, successorship process, and so on.

[0038] The digitized token referred to herein as a digital security token can have functions or features implemented by smart contract code. The digital security token can include different attributes, such as ownership attributes of an entity and/or the token. Embodiments described herein can also provide for the digital issuance of tokens on a blockchain system. The system can enable trading on secondary markets through application programming interfaces (APIs), for example. The system can implement smart contract code to enable utility functions integrated with a digital security token for access to issuer products or services.

[0039] Rights and obligation of the security can be encapsulated in the digital token using program code for smart contracts. The code can be upgradable code to modify features of the smart contracts. Any contracts on the security can be incorporated as code on the token if needed.

[0040] Embodiments described herein can also provide for custodianship and traceability using the blockchain system. For example, there can be a registry of digital security tokens, whitelists, replacement process for lost/stolen tokens, and so on.

[0041] The blockchain system can enable de-centralized peer to peer on-line transactions. Fees involved in existing security exchanges may be levied using smart contract code, for example.

[0042] The digital security token can have the role and function of securities such as a stock and a deed of trust. The digital security token can store a digital image and/or data of the original security that can be recorded, verified and certified using a blockchain-based system. The digital security token can guarantee and safeguard the individual ownership and its associated rights, which can be objectively verified and certified using a blockchain-based system. A printed version of security can be digitized and processed in the same principles and under the same regulations of current securities. [0043] Current security depository services can provide a series of services to the security issuers, including issuance, registration, changes in the format, split/retire of shares and so on in order to provide objectivity and credibility to the securities.

[0044] The digital token can use the blockchain system to handle the services that a current security depository is providing. The related information can be recorded onto blockchain system.

[0045] For the digital token, the digital image and/or data of the security can be the original version and stored on as a DST record on the blockchain system. The digital image and/or data can be kept under the custody of the issuing company or ATS on the blockchain system or the existing security depository services. The hash can be certified or verified using a third party system. The token can be a digital representation of the rightful ownership. The token can be traceable.

[0046] Coordinated recovery of the private key is a useful feature, and according to various embodiments, an improved computing platform system adapted to aid in recovery in the event of a lost key. An encryption based approach is utilized by the computing system to establish, in some embodiments, an authentication key generated during the encryption of a private key is provided that can be split into multiple key fragments or pieces. A subset of the fragments can be required to sign transactions, and in the event of a loss of a private key, a new public/private key pair can be established using the subset of key fragments.

[0047] As described herein in some embodiments, the fragments can be stored at different computing systems and released only after verification and/or validation of identity credentials are adduced (e.g., based on a KYC identifier data value and/or a KYC/AML state). The fragmented key may be established, for example, through the use of a smart contract functionality including executable code that can be invoked to cause signing of the blockchain data record only with the subset of key fragments.

[0048] Figure 1 shows a security token platform for digitized tokens. The platform can provide end to end custodianship and governance management of security token offerings from primary issuance to secondary trading.

[0049] The platform enables registration of digital tokens on a blockchain system 100. The digital (security) tokens can be transferable. The digital (security) tokens can be traced and authenticated using a hash, for example. For example, public key infrastructure (PKI) is a protocol to manage digital certificates and public-key encryption. A PKI based token might not be easily transferred (e.g. if you lost the code then cannot retrieve, a successor might not have the required information). The platform can provide a process for lost keys, successorship, and so on.

[0050] The blockchain system 100 can have a security token blockchain layer 102, a trade history blockchain layer 104, and an Identification blockchain layer 106. The blocks of security token blockchain layer 102, trade history blockchain layer 104, and identification blockchain layer 106 can include upgradable code that can trigger actions and responses automatically. Further details of the different layers are provided in relation to Figure 8.

[0051] The security token blockchain layer 102 provides a custodianship and governance function. The security token blockchain layer 102 creates and maintains the record for the digital (security) tokens. The digital tokens can be created using a digital image of a security that includes an embedded or attached hash. The security token blockchain layer 102 stores the image file and/or the data of securities with the hash. This image can be a scanned copy of the security, for example. For example, an issuing company creates a digital token (e.g. using the digital image and the hash). An issuance system 1 14 can issue security deeds, for example. An investor system 116 can exchange cash or a monetary instrument for the security deeds. The digital tokens can verify and authenticate copies of the security deeds and the tokens can be linked to users or investor systems 116. The security token blockchain layer 102 stores and manages records or blocks of ownership data of security tokens. The ownership data of a block can indicate a digital security token, a hash for the digital security token, and so on. In some embodiments, the digital security token is an image of an original security.

[0052] The identification blockchain layer 106 manages certified user records and can provide a security and compliance function. The identification blockchain layer 106 generates and stores blocks indicating user identifiers and corresponding KYC identifiers. The identification blockchain layer 106 can interact with an external identification provider 110 to verify the digital (security) token and the linked user, as part of a Know Your Client (KYC) or Anti-money laundering (AML) protocol. In some embodiments, the identification blockchain layer 106 stores a KYC identifier at the block, along with other user attributes. The identification blockchain layer 106 can receive a user identifier and a password from a wallet application, for example. The authentication key can be generated using the password linked to the user identifier. The authentication key is an encrypted private key generated by encryption of a private key and the password. The private key can be retrieved by decryption of the authentication key minus the password. The identification blockchain layer 106 stores the authentication key along with the user identifier at the hardware security module (HSM) 108. The user password is not stored and is required along with a randomly generated one-time password to access the authentication key. A password together with a random one-time password may be easier for a user to utilize than managing private keys.

[0053] The trade history blockchain layer 104 provides a traceability function. The trade history blockchain layer 104 maintains transaction records and trade history records for the digital tokens. The digital tokens can be transferred and traded, e.g. using security exchange 112. The trade history blockchain layer 104 maintains records of the transfers and trades. The trade history blockchain layer 104 maintains trade history records to provide traceability of the security. An investor system 1 16 can check the security token blockchain layer 102 to see the initial owner of a digital security token and then the trade history blockchain layer 104 for the history of trades relating to the digital security token. The trade history blockchain layer 104 stores blocks for transactions relating to the digital security tokens. The blocks indicate transaction data attributes such as the digital security token, buyer user identifier, seller user identifier, and date. The trade history blockchain layer 104 can receive a transaction request from a security exchange 1 12.

[0054] A trade transaction record may indicate multiple transaction attributes. Example attributes include: the buyer, the vendor, how much they are paying, how many tokens they are buying, and other details about the transaction. There can be an ownership transaction that indicates who owns the digital (security) token.

[0055] An investor system 1 16 can have an electronic wallet application. The electronic wallet application can authenticate a user during a login process that receives and verifies the password linked to the digital (security) token, for example. The electronic wallet application can be used to participate in trade transactions, for example.

[0056] Figure 2 is a diagram of components of a blockchain system 100 according to some embodiments. The blockchain system 100 has an identification blockchain layer 106 to authenticate users and verify user identifier status. The identification blockchain layer 106 receives sign in credentials (user identifier, password) from a user 202 for provision to HSM 108. The HSM 108 generates an authentication key for identification blockchain layer 106.

[0057] The authentication key is generated for each user identifier received at sign-up. The authentication key is an encrypted private key using the password linked to the user identifier randomized with a one-time password. The private key can be generated by decryption of the authentication key minus the password. This provides an encryption/decryption process.

[0058] The identification blockchain layer 106 has blocks that correspond to verified or certified user identifiers linked to KYC identifiers and status. The digital security token is linked to the user identifier in the security token blockchain layer 102. The block for a user and a token can have attributes. Example attributes include authentication key, KYC Key, status, and so on.

[0059] The identification blockchain layer 106 is linked to an ownership transaction stored in the security token blockchain layer 102 and the trade history blockchain layer 104. The ownership transaction indicates who owns the digital (security) token and the transaction data includes timestamp, date, success/failure, and so on. This can be initiated via a sign-in or internal query, for example.

[0060] The HSM 108 generates the authentication key. The HSM 108 also provides for secure key storage and management. The identification blockchain layer 106 can store the authentication key within the HSM or alternatively, using a decentralized file system such as the Inter-Planetary File System (IPFS).

[0061] Figure 3 is a diagram of components of a blockchain system 100 according to some embodiments. The blockchain system 100 has a trade history blockchain layer 104. The trade history blockchain layer 104 maintains transaction records and trade history records for the digital tokens.

[0062] A security exchange 1 12 sends trade transaction data to the trade history blockchain layer 104. The security exchange 1 12 can receive a trade request from an electronic wallet application 302, for example. The trade request can indicate one or more identifiers for one or more digital tokens. The trade transaction data can indicate a seller identifier, a buyer identifier, one or more identifiers for one or more digital tokens, a quantity of one or more digital tokens, and so on. The security exchange 1 12 can include an application programming interface (API) for the electronic wallet application 302. The security exchange 1 12 can enable security token trading. The security exchange 112 can manage the history of security token prices.

[0063] The trade history blockchain layer 104 generates a trade record block and then stores the block. The trade history blockchain layer 104 can provide an API to security exchange 1 12. The trade history blockchain layer 104 might not record the price of the security, but records the ownership changes, for example. The trade history blockchain layer 104 can generate the trade record block to identify the security token that is the subject of a trade. The trade record block indicates trade attributes such as owner, hash of security, and so on. The trade record block indicates transaction attributes such as buy/sell, transfer, lien, and so on. The trade record block indicates transaction data such as timestamp, date, trade-key, seller, buyer, hash of security, and so on.

[0064] The trade history blockchain layer 104 sends ownership transaction data to the security token blockchain layer 102 to generate and store updated ownership data for the digital token. The trade history records can indicate or identify the digital security token, along with the hash. The security token records can indicate attributes such as the Digital Image, Owner, Tradability, Status, and so on. The security records can relate to different transaction types such as changing ownership, changing deed status, and so on. The trade history blockchain layer 104 refers to the security token blockchain 102 for the digital token’s status and tradability and so on.

[0065] The security token blockchain layer 102 defines assets or records for each security token at initial offering or listing. The security record can indicate digital image load, hash generation, initial owner, and so on.

[0066] In the case of a security token trade, a transaction of ownership change can be authenticated and verified using a smart contract of trade history blockchain layer 104. Such history of changes for a security token can be stored in the security token blockchain layer 102. The security record can relate to ownership changes and can indicate the digital security token and the hash. The record can have attributes such as Digital Image, Owner (Authentication Key), Tradability, Status, and so on. As noted, the security records can relate to different transaction types such as changing ownership, changing deed status, and so on. The security records can indicate transaction data attributes such as timestamp, date, trade key, owner, and so on.

[0067] Figure 4 is a diagram of a blockchain system 100 interacting with a security exchange 112 according to some embodiments. The blockchain system 100 can enable electronic wallet application instance creation or generation. This can be part of a user sign-up process. The investor system 116 can generate a request for an electronic wallet application. The investor system 116 can be linked to a security trading company. The security exchange 112 can receive the request. The security exchange 112 can transmit a request for an authentication key to the blockchain system 100 and in response receive confirmation. The authentication key can be used to sign transactions for the electronic wallet application which is provided to the investor system 116 (e.g. computing device such as a mobile device). The blockchain system 100 can create the private key and create the authentication key. The blockchain system 100 can certify the requesting investor system 116 using a KYC protocol. The blockchain system 100 stores the authentication key and the KYC certification at the HSM 108. The blockchain system 100 stores the authentication key at the identification blockchain layer 106.

[0068] Figure 5 is a diagram of a blockchain system 100 interacting with a security exchange 112 for a security token offering (STO) according to some embodiments. An issuance company 114 system sends a request to issue or list a security token to the security exchange 1 12. The security exchange 112 sends the request for issuance of the security token to the blockchain system 100 and a request for creation of the digital security token on the blockchain architecture. The blockchain system 100 generates and stores the digital security token and transmits a confirmation in response. The security exchange 1 12 transmits requests for the STO or a trade of the security token to the investor system 1 16 and receives monetary consideration in exchange.

[0069] Figure 6 is a diagram of a platform of blockchain systems 100 according to some embodiments. The security token platform provides for the creation and management of security tokens. The system 100 enables end to end custodianship and governance management of security token offerings from primary issuance to secondary trading.

[0070] The platform includes multiple, distributed systems 100 to implements different layers 102, 104, 106. For example, a system 100 (or multiple distributed systems) can implement the security token blockchain layer 102. A system 100 (or multiple distributed systems) can implement the trade history blockchain layer 104. A system 100 (or multiple distributed systems) can implement the identification blockchain layer 106. In some embodiments, a system 100 can implement one or more of the security token blockchain layer 102, the trade history blockchain layer 104, the identification blockchain layer 106.

[0071] Each system 100 can include an I/O Unit 602, a processor 604, communication interface 606, and data storage 610. The processor 604 can execute instructions in memory 608 to implement aspects of processes described herein. The processor 604 can execute instructions in memory 608 to configure one or more of the identification blockchain layer 106, the security token blockchain layer 102, the trade history blockchain layer 104, and other functions described herein. The system 100 may be software (e.g., code segments compiled into machine code), hardware, embedded firmware, or a combination of software and hardware, according to various embodiments.

[0072] The identification blockchain layer 106 provides a security and compliance function. The identification blockchain layer 106 generates and stores blocks indicating user identifiers and corresponding KYC identifiers. The identification blockchain layer 106 can receive a user identifier and a password from a wallet application (e.g. interface application 630). As noted, the authentication key can be generated using the password linked to the user identifier. The security token blockchain layer 102 stores and manages blocks for ownership data. The ownership data of a block can indicate a digital security token, a hash for the digital security token, the authentication key, and so on. In some embodiments, the digital security token is linked to an image of an original security. In some embodiments, the authentication key is an encrypted private key generated by encryption of a private key and the password. The private key can be generated by decryption of the authentication key minus the password.

[0073] The trade history blockchain layer 104 provides a traceability function. The trade history blockchain layer 104 stores blocks for transactions relating to the digital security tokens. The blocks indicate transaction such as the digital security token, the hash for the digital security token, buyer, seller, and date. The buyer or the seller can be linked to the user identifier. The trade history blockchain layer 104 can receive a transaction request from a security exchange 1 12.

[0074] In some embodiments, the buyer is linked to the user identifier and the seller is linked to another user identifier, wherein the security token blockchain layer can process an ownership transaction request indicating the other user identifier, the security token blockchain layer providing verification of the ownership status of the digital security token attached to the user identifier, verification of the active status of the digital security token, execution of smart contract code to enable utility features of the digital security token, the hash for the digital security token, the user identifier linked to the identification blockchain layer providing login authentication, signing of transactions, verification of the active KYC/AML status associated with the user identifier, verification of transaction eligibility between the buyer and seller against a whitelist, the user identifier linked to the trade history blockchain layer storing a record of all transactions related to the digital security token, and linked back to the security token blockchain layer to update the status of the digital security token upon change of ownership. [0075] The I/O unit 602 can enable the system 100 to interconnect with one or more input devices, such as a keyboard, mouse, camera, touch screen and a microphone, and/or with one or more output devices such as a display screen and a speaker.

[0076] The processor 604 can be, for example, a microprocessor or microcontroller, a digital signal processing (DSP) processor, an integrated circuit, a field programmable gate array (FPGA), a reconfigurable processor, among others.

[0077] Memory 608 may include a suitable combination of computer memory that is located either internally or externally such as, for example, random-access memory (RAM), read-only memory (ROM), compact disc read-only memory (CDROM), electro-optical memory, magneto optical memory, erasable programmable read-only memory (EPROM), and electrically-erasable programmable read-only memory (EEPROM), Ferroelectric RAM (FRAM) or the like. Data storage devices 610 can include memory 608, databases 612 (e.g. graph database), and persistent storage 614.

[0078] The communication interface 606 can enable the system 100 to communicate with other components, to exchange data with other components, to access and connect to network resources, to serve applications, and perform other computing applications by connecting to a network (or multiple networks) capable of carrying data including the Internet, Ethernet, plain old telephone service (POTS) line, public switch telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g. Wi-Fi, WMAX), SS7 signaling network, fixed line, local area network, wide area network, and others, including any combination of these.

[0079] The system 100 can be operable to register and authenticate users (using a login, unique identifier, and password for example) prior to providing access to applications, a local network, network resources, other networks and network security devices. The system 100 can connect to different machines, entities 640, and/or data sources 650 (linked to databases 660).

[0080] The data storage 610 may be configured to store information associated with or created by the system 100. The data storage 610 may be a distributed storage system to store blockchain data structures. The data storage 610 can implement databases, for example. Storage 610 and/or persistent storage 614 may be provided using various types of storage technologies, such as solid state drives, hard disk drives, flash memory, and may be stored in various formats, such as relational databases, non-relational databases, flat files, spreadsheets, extended markup files, and so on. A blockchain layer can refer to a distributed ledger data structure with blocks stored on persistent data storage 610. The blocks can be linked via hashing techniques.

[0081] Figure 7 is a diagram of a workflow for blockchain systems according to some embodiments. The systems include the security token blockchain layer 102, the trade history blockchain layer 104, and the identification blockchain layer 106.

[0082] The security token blockchain layer 102 can provide a custodianship and governance function. The security token blockchain layer 102 manages the issuance of the digital securities. The security token blockchain layer 102 stores information or data about the security. This data can include: Digital Image with Hash Code; Owner Information (e.g. User ID); Current Activity Status of Security, and so on.

[0083] The identification blockchain layer 106 provides a security and compliance function. The identification blockchain layer 106 can provide for the creation of the security owner identity. The identification blockchain layer 106 can provide the active status of 3^rd party“know your client” (KYC) and anti-money laundering (AML) features. The identification blockchain layer 106 can create user or security owner records that can store user identifier for the buyer/seller, KYC/AML status and link, and so on. The identification blockchain layer 106 can provide an initial user identifier to the security token blockchain layer 102 to record the initial owner of a digital security token, for example.

[0084] The trade history blockchain layer 104 provides a traceability function. The trade history blockchain layer 104 records the trading history of the digital tokens and stores data relating to trading information, buyer/seller information, security hash code information, and so on. The trade history blockchain layer 104 can implement verification functions for a transaction involving a digital (security) token. The trade history blockchain layer 104 can record data relating to the transaction (and trigger other layers to record data relating to the transaction). The trade history blockchain layer 104 communicates with the security token blockchain layer 102 to verify authenticity and status of the security (e.g. by checking the hash code on the security token). The trade history blockchain layer 104 communicates with the identification blockchain layer 106 to verify the purchaser identity (e.g. checking user identifier against a white list). The trade history blockchain layer 104 updates the ownership record managed by the security token blockchain layer 102 to indicate the buyer/seller data of the transaction. [0085] The security token blockchain layer 102 provides security token related information. Attributes of each security token can be defined in security token blockchain layer 102 at an initial offering. Subsequent changes in ownership or status of security can be maintained in security token blockchain layer 102. [0086] The security token blockchain layer 102 stores a digital image and/or data of the original security and generates a cryptographic hash of the image to represent the true certified copy. A hash of each individual security can be linked to the Digitized Security Token (DST). The security token blockchain layer 102 can record owner information using user identifier (UID) generated on identification blockchain layer 106. No personal information (PI) is stored anywhere on the platform. The security token blockchain layer 102 can maintain the status and tradability of a security represented as a DST. The security token blockchain layer 102 can maintain other relevant information such as Article of Incorporation, corporate documents, and so on.

[0087] The various layers interoperate with one another in concert to provide functionality associated with interactions related to the Digitized Security Token (DST). As described in some embodiments, it may be advantageous to utilize at least these three blockchain layers (e.g., each being a separate blockchain implementation having its own distributed ledger) whereby the information stored thereon is used to provide a secure recovery process in the event that a private key is lost.

[0088] The following table provides an overview of example features:

[0089] The identification blockchain layer 106 can provide a unique user identifier (UID) to all security trade participants. All participants in the platform can be assigned a unique UID via an API during the account creation process when a user selects a login ID and password. The PKI can be generated inside a secure HSM, and encrypted with the users’ password and random one time password and proprietary algorithms to form an authentication key. The private key itself will not be stored anywhere. The User Key consists of encrypting the user’s Private Key with their password and proprietary encryption mechanisms with possible scrambling, randomization and splitting mechanisms to ensure private keys are unknown to anyone but the user. KYC/AML status can be stored in the identification blockchain layer 106. To maintain total privacy, no personal information will be stored in the identification blockchain layer 106 except an ID link to 3rd Party KYC/AML Provider cum personal information holder. A list of hashed user identifiers, and authentication keys can be stored using HSM or IPFS. Users can use User Login ID and their Password and a one-time password to transact the Security.

[0090] The following table provides an overview of example features:

[0091] The trade history blockchain layer 104 provides API to a security trading company, for example. The trade history blockchain layer 104 records all the transactions related to the securities. When DST is traded, the trade history blockchain layer 104 can authenticate and verify the subject security and its status from security token blockchain layer 102. The trade history blockchain layer 104 can also verify UIDs of trade participants against a whitelist from the identification blockchain layer 106.

[0092] When the transaction is completed, the updated ownership and status information can be sent to security token blockchain layer 106 for its update. This process can be carried out by using Smart Contracts of the trade history blockchain layer 104. In some embodiments, the ledger might not record the price of security, but only record the ownership changes. The trade history blockchain layer 104 can record the following transaction data: token : security token; attributes : owner, hash code of security, etc.; transaction record : buy/sell, transfer, lien, etc.; transaction data : date, trade-key, seller, buyer, hash code of security, etc.

[0093] The following table provides an overview of example features that can be recorded on the transaction layer:

[0094] Figure 8 is a diagram of blockchain systems according to some embodiments. As shown, the blockchain systems involve a security token blockchain layer 102, trade history blockchain layer 104, and an identification blockchain layer 106 that can interact with an exchange, alternative trading system, or digital wallet application. [0095] The security token blockchain layer 102 (or digitized security token blockchain) layer can provide a custodianship and governance function. The security token blockchain layer 102 manages the issuance of digitized security tokens (DST).

[0096] The security token blockchain layer 102 implements onboarding of companies for primary issuance of securities. For this process, the security token blockchain layer 102 can create a digital image for each share certificate and generate a hash of the image. The hash can be a cryptography hash, for example. Attributes of each security token can be defined in security token blockchain layer 102 at initial offering.

[0097] The security token blockchain layer 102 can store the digital image and the hash of the image as a DST. The security token blockchain layer 102 can store a certified true digital copy of a share certificate in the form of the DST. The security token blockchain layer 102 can use secure storage, such as a decentralized file system, for example.

[0098] The security token blockchain layer 102 can create and store a ledger for the DST that includes share certificate identifier, owner identifier (UID) or first owner identifier, share properties (e.g. dividends, voting rights). The security token blockchain layer 102 can enable and execute utility features linked to the DST as an encoded smart contract. The utility features can correspond to the share properties, for example.

[0099] The DST can be linked to a DST identifier (DSTID). The DSTID can be a token identifier for company ABC, for example. The DST can be linked to state data, such as active, inactive, cancelled, lien, lockup period, for example. The security token blockchain layer 102 stores information or data about the DST. This data can include: digital image with hash code; ledger of image file ID and hash; ledger of DST, DSTID, state data, owner information (unique user identifier or UID); current activity status of security, and so on. The security token blockchain layer 102 can create and store smart contract code for the DST. The security token blockchain layer 102 does not store personal information. The security token blockchain layer 102 can maintain the status and tradability of the DST. Subsequent changes in ownership or status of security can be maintained in security token blockchain layer 102.

[00100] The identification blockchain layer 106 provides a security and compliance function. The identification blockchain layer 106 can provide for the creation of the security owner identity. The identification blockchain layer 106 can provide active status of 3^rd party“know your client” (KYC) and anti-money laundering (AML) features as part of the user onboarding process. The user can open an account through ATS and provide user attributes (email address, name, physical address, documentation to support identification, and so on). The ATS can be integrated with the blockchain systems via APIs (such as a login API).

[00101] The identification blockchain layer 106 can create a user (owner) account. The identification blockchain layer 106 can leverage a login API to receive a username and password and manage login credentials and authentication keys. Accordingly, the ATS does not need to store passwords or private keys and can leverage the login API to interact with the identification blockchain layer 106. When a user requests a login to their account, the login API receives the username and password and passes this data to the identification blockchain layer 106. [00102] The identification blockchain layer 106 can create user records with UIDs for the buyer/seller, KYC/AML status and link, and so on. The identification blockchain layer 106 can receive a KYC identifier external link (KID) from the login API. The ATS exchange can maintain a list of KIDs and linked personal information. The KID can also have a corresponding state or status, such as active, expired, date performed, results, and so on. The identification blockchain layer 106 can receive KYC/AML data from the ATS. When a user is creating their account via ATS this involves personal information (PI). The ATS stores the PI linked to the KID. The KID points to the storage location of the PI so that this is not stored on the identification blockchain layer 106.

[00103] The identification blockchain layer 106 stores a ledger of UIDs and corresponding KIDs. The identification blockchain layer 106 can store a ledger of KID states. The identification blockchain layer 106 can store a whitelist of UIDs. The whitelist of UIDs can indicate accredited buyers/sellers along with geographic information, for example. There may be no personal information stored in the whitelist. The identification blockchain layer 106 does not store personal information of the user. The login API can enable user login to access the account without receiving the personal information of the user.

[00104] The identification blockchain layer 106 can generate an authentication key which can be an encrypted private key generated using the password. The identification blockchain layer 106 can store the user key at an HSM. The identification blockchain layer 106 can generate PKI (private/public keys) data. The identification blockchain layer 106 can generate a hash of UIDs and stored the hashed UIDs at the HSM. The HSM can store authentication keys linked to user identifiers. This data can remain in the HSM and not leave the HSM for security. For example, the HSM can use the password (received via login API) to generate a PKI private/public key pair. The HSM can use physical randomness to generate the key pair, for example. There can be levels of security such as hardware security, layers of encryption methods, one-time passwords, randomization, and so on.

[00105] The identification blockchain layer 106 can link the authentication key (e.g. the encrypted private key) to the owner using a hashed version of the UID (which can also be linked to the username). When the identification blockchain layer 106 receives the UID it can generate a hash to locate the authentication key. The identification blockchain layer 106 receives the password via the login API and then can retrieve the private key via the authentication key. After login, the user can send commands (via an interface application) to trigger actions by the identification blockchain layer 106.

[00106] The identification blockchain layer 106 can provide secure password management for example, using Distributed Credential Protection (DCP). DCP can authenticate login passwords without directly storing the password itself. If a user wants to change a password, then this is updated at the DCP. This can also trigger an update to the authentication key (while underlying private key stays the same).

[00107] The identification blockchain layer 106 can provide an initial user identifier to the security token blockchain layer 102 to record the initial owner of a digital security token, for example.

[00108] If a user forgets his/her password or login ID, they can interact with the ATS exchange to prove their legal identity. Their identification data can be linked to a KID (by ATS exchange). The KID can be linked by the blockchain system to the UID. For example, the identification blockchain layer 106 can store a ledger of UIDs and KIDs. The security token blockchain layer 102 can cross reference the UID to DSTIDs to identify DSTs that are owned by the user. The security token blockchain layer 102 can cancel the DST via state data (inactive) and reissue new DSTs under the UID, for example.

[00109] The trade history blockchain layer 104 provides a traceability function. The trade history blockchain layer 104 connects with ATS exchange via a trade API to receive trade data. The trade history blockchain layer 104 records the trading history of the digital tokens and stores data relating to trading information, buyer/seller information, security hash code information, and so on. The trade history blockchain layer 104 stores a ledger of trades. The trade history blockchain layer 104 stores a ledger of UIDs and DSTIDs.

[00110] The trade history blockchain layer 104 can implement verification functions for a transaction involving a digital (security) token.

[0011 1] The trade history blockchain layer 104 communicates with the security token blockchain layer 102 to verify authenticity of the DST and status of the DST (e.g. by checking the DSTID). The trade history blockchain layer 104 communicates with the identification blockchain layer 106 to verify the UID (e.g. checking UID against a white list). The trade history blockchain layer 104 updates the ownership record managed by the security token blockchain layer 102 to indicate the buyer/seller data of the transaction. The trade history blockchain layer 104 updates the security token blockchain layer 102 to indicate a recent owner (UID), for example. The trade history blockchain layer 104 can create a lifecycle record of a DST (via the DSHD).

[00112] The trade history blockchain layer 104 records all the transactions related to the securities. When DST is traded, the trade history blockchain layer 104 can authenticate and verify the subject DST and its status from security token blockchain layer 102. The trade history blockchain layer 104 can also verify UIDs of trade participants against a whitelist of UIDs from the identification blockchain layer 106. When the transaction is completed, the updated ownership and status information can be sent to security token blockchain layer 106 for its update. This process can be carried out by using Smart Contracts of the trade history blockchain layer 104. In some embodiments, the ledger might not record the price of security, but only record the ownership changes. The trade history blockchain layer 104 can record the following transaction data: token : security token; attributes : owner, hash code of security, etc.; transaction record : buy/sell, transfer, lien, etc.; transaction data : date, trade-key, seller, buyer, hash code of security, etc.

[00113] The blockchain architecture can prevent hacking or mirroring the blockchain layers (they are not just servers).

[00114] Embodiments described herein provide a security token with utility features (code). Embodiments described herein provide end to end custodianship. Embodiments described herein provide privacy (not storing PI). Embodiments described herein provide security using distributed ledgers over blockchain layers. Embodiments described herein provide lifecycle traceability. Embodiments described herein use a multi-layered approach to provide an integrated engine. This model offloads the private key management for users (while still having the benefits of the blockchain).

[00115] Figure 9 is a diagram of a system for generating and storing secure keys according to some embodiments.

[00116] The system includes two example hardware security modules HSM 1 902, HSM 2 904. The HSM 1 902 can have a random number generator and PKI generator. The HSM 1 902 can store UID hash and authentication keys in a secure manner. The HSM 2 904 can have a random number generator and a one-time password (OTP) generator. The HSM 2 904 can generate different passwords (OTP 1 . OTP N). The HSM 2 904 can store UID and replace the OTP N-

1 with OTP N if authentication is successful. The HSM 2 904 can provide 2 factor authentication for OTP N which can be used as an example password. The HSM 1 902 enables user login authentication and can receive the UID, for example.

[00117] The HSM 1 902 enables PKI generation (inside the HSM) and randomization encryption of the private key using the password and the OTP N-1 (stored at HSM 2 904), for example. The encryption of the private key generates authentication key N-1 which is stored at HSM 1 902. The user login is authenticated using the password and OTP N (stored at HSM 2 904). The private key can be retrieved to enable randomization encryption of the private key to generate authentication key N which is stored at HSM 1 902.

[00118] Known PKI based systems can be difficult for using wallet address (e.g. random hash number) because if one is to lose the PKI then there is no way to recover them. This makes full observation of property rights difficult. If a system uses an identifier and password stored in a centralized location, then it can be vulnerable to cyber-attack.

[00119] In accordance with embodiments described herein, the PKI can be encrypted with the password (“Pepper”) with constant“Salt” (or another example constant). The encrypted PKI can be linked to the user identifier. As a further enhancement, in some embodiments, the encrypted PKI also can be split into three keys or pieces. A user can use two keys (e.g. portions of the encrypted PKI) to sign the transaction.

[00120] The system processes the transaction by combining two keys, a portion (1/3) of the encrypted PKI can be stored at wallet, a portion (1/3) of the encrypted PKI can be stored in blockchain cloud, and a portion (1/3) of the encrypted PKI can be stored with other onboarding agent. The wallet can send the transaction with its portion of the encrypted PKI to the blockchain cloud to verify it.

[00121] If a user loses a portion, then they can go to onboarding agent to retrieve it. When someone applies for the wallet then the onboarding agent can also encrypt and store a portion of PKI so they can go back to the onboarding agent. For example,“xpriv” is the master private key of the wallet and is secured using an enhanced threshold cryptography. In this example“xpriv” can be split into 3 fragments and 2 key fragments are required to sign transactions. This can be done at a Cloud Key Service (identification blockchain layer 106) for example. Key fragment A can be encrypted and stored at distributed nodes with each of the linked device’s PKI 2048-bit RSA private key and the user-selected PIN or password (“Pepper”) with“Salt.” Key fragment B can be stored on device or backed up at IPFS or HSM 108. Key fragment C can be stored on- boarding agent’s secured encrypted key storage, encrypted with the on-boarding agent’s PKI, used for recovering of key fragment B in case of total loss of all devices which store Key Fragment B for a user.

[00122] When the user loses all of their linked devices, the user can report the loss and this can trigger an identification check by on-boarding agent to ensure that user is who he/she claims to be. Key fragment C can be stored at an on-boarding agent computing system in case the user forgets his/her password.

[00123] Figure 10 is a diagram of an authentication key generation process. The process can provide for an abstraction of a computer-friendly private key to a human-friendly private key.

[00124] Public key cryptography, or asymmetric cryptography, is a cryptographic system that uses pairs of keys: public keys which may be disseminated widely, and private keys which are known only to the owner. The generation of such keys depends on cryptographic processes to produce one-way functions. Effective security requires keeping the private key private; the public key can be openly distributed without compromising security.

[00125] A private key is intended to remain private and shared with no one, under any circumstance. A public key, in contrast, can be shared with anyone. There is no danger in the user placing the user’s public key on the website, for example, or to e-mail it to a client to receive payment for some activity. Public key allows the user to identify oneself, while the private key allows the user to prove the user is that person. However, unlike a password, a private key can never be reset or recovered if lost. Thus, a private key is an extremely important piece of data and should be protected.

[00126] Public and private key pairs are fundamental tools in cryptography. As an example, in cryptocurrencies, control over funds is asserted by creating a digital signature, which involves using the private key. Public and private key pairs are to confirm ownership and create a large pool of addresses available for use.

[00127] The following provides an example of Private Key as a 256-bit number

1 Private Key:

2 KxeNcRw8mBfyLrnnXQymQkogLjvmn6uJCmSWLRmZ6Mt3Hzfgo1 mY

3

4 Deposit Address: 5 1 M n U 3iyTeej69 D KGG Ko6vU 3 H 3d KKZ9ZL6u

[00128] Due to a large number of the total address space of keys (2¹⁶⁰ when to use 256-bit encryption), one might assume that any key the user generates belongs to the user and only to the user. Thus, the public key based system requires no further proof of ownership. Otherwise, in other systems, they traditionally use the user’s identity as proof of ownership. Since the public key based system removes this requirement, the transactions stay in anonymity.

[00129] Private keys give the users complete control over their transactions. However, in many ways, having complete control is frightening. If a private key is lost, the funds associated with it are gone, forever. If someone steals a private key, they have complete access to the funds, and theoretically, are the new owner of said funds. And, there is no recourse in the event of private key loss, theft, or any other issue.

[00130] It can be difficult to safeguard a private key. It can be difficult to remember even a single private key. They are long and unwieldy. What is useful to a computer system (large numbers, data sets, and lengthy strings) is often very annoying to human beings. Managing a private key is a lot of pressure on a public key based system, especially one that handles digital security tokens. A user could do what they do with any other valuable data, and create a backup private key. However, private keys should be very closely guarded.

[00131] Private keys should not be backed up on a cloud server or transmitted through internet communication of any kind to avoid any potential exposure to malicious attack. Storing them on a computer or mobile device is dangerous, for if a system is compromised by a thief or attacker, all of the digital asset associated with private keys on the system would be free for the taking.

[00132] A private key generally cannot be reset or recovered if lost. The whole security of the public key based system handling digital asset is to not be able to derive the private key from the public key. A private key that is an input for that hash process can produce its corresponding public key. However, the public key cannot be reverse engineered to produce its corresponding private key due to the one-sided nature of the process. If so, it would make the whole public key based system useless. Unless the user has a seed (usually some 12 words) noted down, or the private key in a file (e.g. "wallet.dat"), there is basically no access to your funds. Lost private key means lost digital assets associated with that private key. In accordance with embodiments described herein, the key is recoverable. [00133] The transactions generally stay in anonymity. A transaction changes the state of the agreed-correct blockchain. A blockchain is a shared, decentralized, distributed state machine. This means that all nodes (users of the blockchain system) independently hold their own copy of the blockchain, and the current known "state" is calculated by processing each transaction in order as it appears in the blockchain. Transactions are bundled and delivered to each node in the form of a block. As new transactions are distributed throughout the network, they are independently verified and "processed" by each node. This constant movement of tokens is what constitutes the data within any blockchain architecture.

[00134] All the transaction on the public key based system does not require proof of ownership as the authenticity of the transaction is verified using public key and private key pair, and some form of consensus algorithms among all participating nodes. This creates anonymity much like physical cash. However, if a digital token derives its value from an external, tradable asset, it can be classified as a security token and becomes subject to securities regulations, for example. Failure to abide by these regulations including Know Your Client (“KYC”) and Anti-Money Laundering (“AML”) could result in costly penalties and may stall or eliminate a project. In accordance with embodiments described herein, the transactions can be linked to identifiers.

[00135] While preserving public key cryptography’s security features, embodiments described herein can provide for the abstraction of the computer-friendly public key system to human- friendly public key system. The private key is safely protected while not diminishing the ease of use for human. It can accommodate the accustomed human behavior such as user selected identification and password. There can be a mechanism to recover the loss of private key (or fragment of private key). There can be a legally compliant process of identifying ownership of digital tokens or participant of transactions.

[00136] The embodiments described herein can use public key cryptography and a threshold cryptosystem. The solution can work with different cryptographic algorithms.

[00137] As an example, consider the Elliptical Curve Digital Signature Algorithm 256 bits (prime field (“ECDSA”)). Private keys produce a public key pair via an Elliptical Curve Digital Signature Algorithm 256 bits (prime field (“ECDSA”). ECDSA works over a large group of prime size, in which the group operation is easy to compute, but the discrete process is computationally infeasible. The definition of the group is called the "key parameters". Key parameters may be shared between different key pairs with no ill effect on security; this is the usual case with ECDSA in particular. ECDSA uses the following key parameters: E, an elliptic curve, defined over a given finite field; q, a sufficiently large prime number (at least 160 bits) that is a divisor of the curve order; G a point of E, of order q.

[00138] The group on which ECDSA will be computed can involve the curve points jG (multiplication of point G by integer j) where j ranges from 0 to q-1. G is such that qG = 0 (the "point at infinity" on the curve E). The size of the group is q. Note that these notations are used in order to match those used for DSA. ECDSA private key is an integer x taken modulo q. The relevant standards prescribe that x shall not be 0; hence, x is an integer in the range [1 , q-1]

[00139] ECDSA public key is computed from the private key x and the key parameters. The public key is the curve point: U = xG

[00140] The system uses a key pair. For example, consider ECDSA on the curve K-163. The curve is defined over a field GF (2^L163): field elements are encoded into 163-bit strings. The order of the conventional base point is the prime value: q =

0x4000000000000000000020108A2E0CC0D99F8A5EF which has length qlen¹ = 163 bits. The private key is: x = 0x09A4D6792295A7F730FC3F2B49CBC0F62E862272F

[00141] The corresponding public key is the curve point U = xG. This point has two coordinates, which are elements of the field GF(2^A163). These elements can be converted to integers, yielding the two public point coordinates: Ux = 0x79AEE090DB05EC252D5CB4452F356BE198A4FF96F; Uy= 0x782E29634DDC9A31 EF40386E896BAA18B53AFA5A3

[00142] Using the above parameters, the system can calculate r, the first half of a generated signature, and b, input bits, as follows rlen is equal to qlen, rounded up to the next multiple of 8 (if qlen is already a multiple of 8, then rlen equals qlen; otherwise, rlen is slightly larger, up to qlen+7). Note that rlen is unrelated to the value r, the first half of a generated signature blen is the length (in bits) of an input sequence of bits and may vary between calls blen may be smaller than, equal to, or larger than qlen.

[00143] The system can use bit string to integer or bits2int during signature generation and verification in ECDSA to transform a hash value (computed over the input message) into an

¹ A group order length integer modulo q. That is, the integer obtained through bits2int is further reduced modulo q; since that integer is less than 2^Aqlen, that reduction can be performed with at most one subtraction.

[00144] The sequence is first truncated or expanded to length qlen. If qlen < blen, then the qlen leftmost bits are kept, and subsequent bits are discarded. Otherwise, qlen-blen bits (of value zero) is added to the left of the sequence (i.e. , before the input bits in the sequence order).

[00145] The resulting sequence is then converted to an integer value using the big-endian convention: if input bits are called b_0(leftmost) to b_(qlen-1) (rightmost), then the resulting value is: b_0*2^A(qlen-1) + b_1*2^A(qlen-2) + ... + b_(qlen-1)*2^A0

[00146] The system can use integer to octets (int2octets) which can defined under the name "Integer-to-OctetString". It can be used in the specification of the encoding of an ECDSA private key (x) within an ASN.1-based structure. An integer value x less than q (and, in particular, a value that has been taken modulo q) can be converted into a sequence of rlen bits, where rlen = 8*ceil(qlen/8). This is the sequence of bits obtained by big-endian encoding. In other words, the sequence bits xj (for i ranging from 0 to rlen-1) are such that: x = x_0*2^A(rlen-1) + x_1*2^A(rlen- 2) + ... + x_(rlen-1)

[00147] This transform can be referred to as int2octets. For this example, since rlen is a multiple of 8 (the smallest multiple of 8 that is not smaller than qlen), then the resulting sequence of bits is also a sequence of octets, hence the name.

[00148] The system can use bit string to octets (bits2octets) in the specification of deterministic ECDSA. The bits2octets transform takes as input a sequence of blen bits and outputs a sequence of rlen bits. This can involve the following steps: the input sequence b is converted into an integer value z1 through the bits2int transform: z1 = bits2int(b). For this example, z1 is reduced modulo q, yielding z2 (an integer between 0 and q-1 , inclusive) and z2 = z1 mod q.

[00149] Note that since z1 is less than 2^Aqlen the modular reduction can be implemented with a conditional subtraction: z2 = z1-q if that value is non-negative; otherwise, z2 = z1.

[00150] Then z2 is transformed into a sequence of octets (a sequence of rlen bits) by applying int2octets.

[00151] The system can generate the signature using the following example process. [00152] Signature generation uses a cryptographic hash function H and an input message m. The message is first processed by H, yielding the value H(m), which is a sequence of bits of length hlen. Normally, H is chosen such that its output length hlen is roughly equal to qlen, since the overall security of the signature scheme will depend on the smallest of hlen and qlen; however, the relevant standards support all combinations of hlen and qlen.

[00153] The following steps are then applied. H(m) is transformed into an integer modulo q using the bits2int transform and an extra modular reduction: h = bits2int(H(m)) mod q

[00154] As was noted in the description of bits2octets, the extra modular reduction can be a conditional subtraction.

[00155] A random value modulo q, dubbed k, is generated. That value shall not be 0; hence, it lies in the [1 , q-1] range. The following describes the process used to generate k. In plain ECDSA, k should be selected through a random selection that chooses a value among the q-1 possible values with uniform probability.

[00156] A value r (modulo q) is computed from k and the key parameters: the point kG is computed; its X coordinate (a member of the field over which E is defined) is converted to an integer, which is reduced modulo q, yielding r. If r turns out to be zero, a new k should be selected and r computed again (this is an utterly improbable occurrence).

[00157] The value s (modulo q) is computed as follows s = (h+x*r)/k mod q

[00158] The pair (r, s) is the signature. An example way is to use a DER-encoded ASN.1 structure (a SEQUENCE of two INTEGERS, for r and s, in that order).

[00159] The system can implement the generation of k using the following example process.

[00160] The value k is used to compute the first half of the signature, dubbed r. The DSA and ECDSA standards mandate that, if r is zero, then a new k should be selected. In that situation, the value k can be "unsuitable", and the generation process shall keep on looping.

[00161] In this example, the system uses the hash function SHA-256 [FIPS-180-4] The input message is the UTF-8 encoding of the string "sample" (6 octets, i.e. , 48 bits).

[00162] The hashed input message hi = SHA-256(m) is hi AF 2B DB E1 AA 9B 6E C1 E2 AD E1 D6 94 F4 1 F C7

1A 83 1 D 02 68 E9 89 15 62 11 3D 8A 62 AD D1 BF

(32 octets; each octet value is listed in hexadecimal notation).

[00163] The system can convert the private key x to a sequence of octets using the int2octets transform: int2octets(x)

00 9A 4D 67 92 29 5A 7F 73 OF C3 F2 B4 9C BC OF

62 E8 62 27 2F

[00164] Although the specific value of x would numerically fit in 160 bits, i.e. , 20 octets, the system can encode x into 21 octets, because the encoding length is driven by the length of q, which is 163 bits.

[00165] They can truncate and/or expand the hashed message using bits2octets: bits2octets(h1)

01 79 5E DF 0D 54 DB 76 OF 15 6D 0D AC 04 CO 32 2B 3A 20 42 24 [00166] The steps b to g then compute the values for the K and V variables. These variables are sequences of 256 bits (the hash function output length, rounded up to a multiple of 8). The following provides the successive values:

[00167] V after step b:

01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

[00168] K after step c:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [00169] K after step d:

09 99 9A 9B FE F9 72 D3 34 69 11 88 3F AD 79 51 D2 3F 2C 8B 47 F4 20 22 2D 1 1 71 EE EE AC 5A B8 [00170] V after step e: D5 F4 03 OF 75 5E E8 6A A1 OB BA 8C 09 DF 11 4F F6 B6 11 1C 23 85 00 D1 3C 73 43 A8 CO 1 B EC F7 [00171] K after step f:

OC F2 FE 96 D5 61 9C 9E F5 3C B7 41 7D 49 D3 7E A6 8A 4F FE DO D7 E6 23 E3 86 89 28 99 11 BD 57 [00172] V after step g:

78 34 57 C1 CF 31 48 A8 F2 A9 AE 73 ED 47 2F A9 8E D9 CD 92 5D 8E 96 4C EO 76 4D EF 3F 84 2B 9A

[00173] The system performs the final loop. In the example that uses HMAC with SHA-256, this produces 256 bits worth of output, and the system needs only 163 bits for T, a single HMAC invocation yields the following T: T (first try)

93 05 A4 6D E7 FF 8E B1 07 19 4D EB D3 FD 48 AA

20 D5 E7 65 6C BE OE A6 9D 2A 8D 4E 7C 67 31 4A

[00174] When converted to an integer with bits2int, yields a first candidate for k: k1 = 0x4982 D236F3 F FC758838CA6 F5E9F EA455106AF3 B2 B [00175] Since that value is greater than q-1 , the system has to loop. This first entails computing new values for K and V: new K 75 CB 5C 05 B2 A7 8C 3D 81 DF 12 D7 4D 7B EO AO

E9 4A B1 98 15 78 1 D 4D 8E 29 02 A7 9D OA 66 99

new V

DC B9 CA 12 61 07 A9 C2 7C E7 7B A5 8E A8 71 C8

C9 12 D8 35 EA DD C3 05 F2 44 5D 88 F6 6C 4C 43

[00176] The system can then generate a new T :

T (second try)

C7 OC 78 60 8A 3B 5B E9 28 9B E9 OE F6 E8 1A 9E

2C 15 16 D5 75 1 D 2F 75 F5 00 33 E4 5F 73 BD EB

[00177] and a new candidate for k:

k2 = 0x63863C30451 DADF4944DF4877B740D4F 160A8B6AB

[00178] Since k2 is also greater than q-1 , the system can loop again: new K (2)

OA 5A 64 B9 9C 05 95 20 10 36 86 CB 6F 36 BC FC

A7 88 EB 3B CF 69 BA 66 A5 BB 08 OB 05 93 BA 53

new V (2)

OB 3B 19 68 11 B1 9F 6C 6F 72 9C 43 F3 5B CF OD

FD 72 5F 17 CA 34 30 E8 72 14 53 E5 55 50 A1 8F

[00179] T (third try)

47 5E 80 E9 92 14 05 67 FC C3 A5 OD AB 90 FE 84

BC D7 BB 03 63 8E 9C 46 56 AO 6F 37 F6 50 8A 7C [00180] and the system can generate an acceptable value for k:

[00181] k = 0x23AF4074C90A02B3FE61 D286D5C87F425E6BDD81 B

[00182] The system can generate a signature. With the private key and the value of k that was generated, the system can now compute the signature using the ECDSA mechanisms. First, the point kG is computed, and the X coordinate of that point is converted to an integer and then reduced modulo q, yielding the first signature half: r = 0x113A63990598A3828C407C0F4D2438D990DF99A7F

[00183] which the system uses, together with x (the private key), k (which was determined above), and h = bits2int(h1), to compute the second signature half: s = 0x1313A2 E03F5412 D D B296A22 E2C455335545672 D9F

[00184] An ECDSA signature is a pair of integers. In many protocols that require a signature to be a sequence of bits (or octets), it is customary to encode the signature as an ASN.1

SEQUENCE of two INTEGER values, with DER rules. This results in the following 48-octet signature:

30 2E 02 15 01 13 A6 39 90 59 8A 38 28 C4 07 CO F4 D2 43 8D 99 0D F9 9A 7F 02 15 01 31 3A 2E 03 F5 41 2D DB 29 6A 22 E2 C4 55 33 55 45 67 2D 9F

[00185] The system can use a threshold ECDSA.

[00186] The system can use a threshold cryptosystem. The basis for the field of threshold cryptography, is a cryptosystem that protects information by encrypting it and distributing it among a cluster of fault-tolerant computers. Wth a threshold cryptosystem, in order to decrypt an encrypted message or to sign a message, several parties (more than some threshold number) must cooperate in the decryption or signature protocol.

[00187] Threshold cryptography refers to splitting cryptographic keys such that performing an operation— such as decrypting or signing a message— requires an interactive process among multiple shareholders without ever disclosing the secret. Threshold ECDSA refers to the digital signature algorithm hard-coded by most cryptocurrencies.

[00188] For the rest of the blockchain, there can be a single key used to create one signature; transactions consume the same amount of space as single key addresses. On the other hand, that key has been shared into multiple shares, with each share given to a different party. Those shares might never reassembled. Instead, the people controlling individual shares all participate in a complex protocol to create the signature, without any participant gaining more information about the shares held by others. Designing those protocols, reasoning about their properties and proving security involves cryptographic techniques. It is also where the complexity lies. Depending on the particular problem, these protocols can be too unwieldy for implementation.

[00189] For the ECDSA process, including its elliptical curve incarnation, the amount of interaction required among holders of shares during signature generation is a bottleneck. In a solution, no interaction is required. Each person performs a computation using their share working independently and outputs some intermediate result. Finally, there is a reassembly phase, where an untrusted system collects the partial answers and reassembles them into a final result. These bridges can be viewed as a step towards a decentralized system or with some amount of centralization depending on the use cases.

[00190] Referring back to Figure 10, the diagram illustrates an authentication key generation process. The process can involve an authorized KYC agent and a user. The user requests onboarding by the authorized KYC agent. The agent can call the identification blockchain API to generate an authentication key for the user. The system calls the blockchain identification layer 106 via an API. The user provides the user ID or identifier and password. The authorized KYC agent calls the identification blockchain API to store KYC information in data storage. The KYC information can be linked to the identifier or user ID. In this example, the computed parameters lu and Ku are stored in data storage lu is a hash of User Id, and Ku is a hash of (Private Key + Password + Salt).

[00191] At 1000, the system (or the blockchain identification layer 106) calls the private key generation module. This can be via the API. For example, the call can be:

ECKeyPairGenerator gen = new ECKeyPairGenerator("ECDSA");

SecureRandom SecureRandom = new SecureRandomQ; [00192] Private Key Generation module can reside in secure hardware element such as HSM 108 or can be distributed on Identification Blockchain 106 API.

[00193] At 1001 , the Private Key Generation module generates different parameters, such as q and j, and computes parameters, such as G. For example, this can involve: ECDomainParameters ecSpec = new ECDomainParameters(ecp. Curve, ecp.G, ecp.j, ecp.q,

[00194] At 1002, the system checks qG. This can involve generating a seed and compares parameters. This can involve: ecp.GetSeedO).

ECKeyGenerationParameters ecgp = new ECKeyGenerationParameters(ecSpec, SecureRandom):

Gen.lnit(ecgp)

[00195] The system checks if qG=0 and if not, returns back to 1001 in some implementations.

[00196] At, 1003, the system checks if alternative multi_party_ecdsa is used, and if so, goes to operation 10005. This can involve checking n(x) to see if greater than one. [00197] At 1004, the system computes different parameters, such as U=xG and can involve different application calls such as the following:

AsymmetricCipherKeyPair eckp = gen.GenerateKeyPair();

ECPrivateKeyParameters ecPri = (ECPrivateKeyParameters)eckp. Private; //x1=mod(q) ECPublicKeyParameters ecPub = (ECPublicKeyParameters)eckp. Public; //U=x1G byte[] pub = ecPub. Q.GetEncoded(); // Public Key byte[] pri = ecPri. D.ToByteArray() // Private Key byte[]pubX = ecPub. Q.XCoord.ToBiglnteger().ToByteArray().ToHex(); // Store public key coordinate x byte[]pubY = ecPub.Q.YCoord.ToBiglnteger().ToByteArray().ToHex(); // Store public key coordinate y

[00198] At 1005, the system computes different parameters, such as the following:

AsymmetricMultiParyEcdsa ec_secp256k1 = gen.GenerateKeyPair(); ECPrivateKeyParameters ecPri = (ECPrivateKeyParameters)ec_secp256k1 Private //x1 , x2,....,xn = rsa(mod(q))

ECPrivateKeyParameters ecPub = (ECPublicKeyParameters)ec_secp256k1 Public

[00199] To provide added security and recoverability of private key, Multi Party ECDSA can be adopted as an option. [00200] At 1006, the system computes different parameters, such as lu, Ps, Ku. This can involve the following: hashedpw=sha256(pw, salt) // Hashed value of salt added password string byte[] uniqueid=sha256(id) // Hash of provided user identifier byte[] userkey=sha256(x,Ps) // Hash of private key with hashed password [00201] The following table is an example of a hashed password

key, and updates the data storage with new data. The system can store lu and Ku in the data storage. The KYC/AML data can be obtained via the blockchain 106 API. Accordingly, the authentication key (or encrypted private key) can be generated and stored by the process. The key is stored linked the user ID or identifier. [00203] Figure 11 is a diagram of a DST transaction process. The process involves a seller and the buyer. The seller can call the trade history blockchain API with message data. The message data can include an identifier and password. The message data can include origination party, termination party, transaction type, security token Hash code, Smart contract details, and so on.

[00204] The trade history blockchain API can in turn call the identification blockchain API to retrieve data linked to the identifier. The identification blockchain layer stores different records that link identifiers with authentication keys and other data. The identification blockchain layer uses the identifier to retrieve the user key or the authentication key stored in data storage. The identification blockchain layer can decrypt the user key or the authentication key using the password in order to obtain the private key. The private key is used to create a signature.

[00205] The trade history blockchain API can in turn call the security token blockchain API two look up data on the blockchain with the security token hash code. The security token blockchain can retrieve the current activity status and check trade ability of the security token. If the token is not tradable than the transaction fails. If the token is tradable then encrypted messages generated using the signature.

[00206] The seller provides the public to the buyer. The security token blockchain layer can authenticate the message with the provided public key. If the message is not authenticated, then the transaction fails. If the message is authenticated, then the transaction is accepted and the data is broadcast to the trade history blockchain.

[00207] Figure 12 is a diagram of a DST retrieval process. The process can be used to recover lost data, such as a lost user identifier or private key. The authorized KYC agent received KYC documents from the user. The authorized KYC agent verifies the KYC documents. The authorized KYC agent checks if the provided KYC data matches. If there is no match, then the system returns a retrieval fail message.

[00208] The system calls identification blockchain API to look up data storage with KYC data (KID). In response, the identification blockchain retrieves the user ID or identifier linked to the KYC data. The system calls the security token blockchain API to look up the blockchain with the user identifier. The system determines whether the user ID is the same as the transaction ID (DSTID). If so the system changes the status of the DST to an active and issues a new DST to be broadcast to the trade history blockchain. If not, then the system returns a retrieval failure. [00209] The following discussion provides many example embodiments of the inventive subject matter. Although each embodiment represents a single combination of inventive elements, the inventive subject matter is considered to include all possible combinations of the disclosed elements. Thus if one embodiment comprises elements A, B, and C, and a second embodiment comprises elements B and D, then the inventive subject matter is also considered to include other remaining combinations of A, B, C, or D, even if not explicitly disclosed.

[00210] The embodiments of the devices, systems and methods described herein may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface.

[0021 1] Program code is applied to input data to perform the functions described herein and to generate output information. The output information is applied to one or more output devices. In some embodiments, the communication interface may be a network communication interface. In embodiments in which elements may be combined, the communication interface may be a software communication interface, such as those for inter-process communication. In still other embodiments, there may be a combination of communication interfaces implemented as hardware, software, and combination thereof.

[00212] Throughout the foregoing discussion, numerous references will be made regarding servers, services, interfaces, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor configured to execute software instructions stored on a computer readable tangible, non-transitory medium. For example, a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions.

[00213] The technical solution of embodiments may be in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided by the embodiments. [00214] The embodiments described herein are implemented by physical computer hardware, including computing devices, servers, receivers, transmitters, processors, memory, displays, and networks. The embodiments described herein provide useful physical machines and particularly configured computer hardware arrangements. [00215] Although the embodiments have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein.

[00216] Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. [00217] As can be understood, the examples described above and illustrated are intended to be exemplary only.

Claims

WHAT IS CLAIMED IS:

1. A system for digital security tokens comprising: a server or network of servers having non-transitory computer readable storage medium with executable instructions for causing one or more processors to configure: an identification blockchain layer for receiving a user identifier, a user password, KYC identifier and KYC/AML state; generating a private key at secure hardware element; encrypting the private key into an instance of an authentication key using the password and a random one-time code; and storing a record of the user identifier and the authentication key, the record not storing any personal information, the private key or the password; a security token blockchain layer for receiving the user identifier, ownership data indicating a digital security token, a hash for the digital security token, and data indicating the state of the security token, generating a digital security token identifier, and storing a record of the digital security token indicating the digital security token identifier, a state, and the ownership data without storing any personal information; and a trade history blockchain layer for receiving a transaction request from a security exchange, the transaction request linked to transaction data indicating the digital security token identifier, a buyer identifier, and seller identifier, wherein the buyer or the seller is linked to the user identifier, and storing a record for the transaction data upon verification, the record not storing any personal information, the trade history blockchain layer configured to verify the digital security token identifier with the security token blockchain layer and verify the user identifier with the identification blockchain layer; the identification blockchain layer configured to receive a recovery request with the KYC identifier and retrieve the user identifier using the KYC identifier; the security token blockchain layer configured to retrieve the record of the digital security token identifier using the user identifier, update the data indicating the state of the security token to inactive, issue a new digital security token having a new digital security token identifier; generate a new record of the new digital security token indicating the digital security token identifier, a state, and the ownership data without storing any personal information; and the trade history blockchain layer configured to update the record for the transaction data with the new digital security token.

2. The system of claim 1 wherein the identification blockchain layer is configured to generate a new record with the user identifier and a new authentication key, the new authentication key generated by encrypting a new private key using the password.

3. The system of claim 1 wherein the authentication key is split into a plurality of portions.

4. The system of claim 1 wherein the authentication key is split into three fragments and two key fragments of the three key fragments are required to sign transactions by the trade history blockchain layer.

5. The system of claim 1 wherein the trade history blockchain layer receives the transaction request and calls the identification blockchain layer to retrieve the authentication key with the user identifier, decrypt the authentication key with the password to retrieve the private key and generate a signature to encrypt and authenticate the record for the transaction data.

6. The system of claim 1 wherein the buyer is linked to a user identifier and the seller is linked to another user identifier, wherein the security token blockchain layer can process an ownership transaction request indicating the user identifier, the security token blockchain layer providing verification of the ownership status of the digital security token attached to the user identifier, verification of the active status of the digital security token, the user identifier linked to the identification blockchain layer providing login authentication, signing of transactions, verification of the active KYC/AML status associated with the user identifier, verification of transaction eligibility between the buyer and seller against a whitelist, the user identifier linked to the trade history blockchain layer storing a record of all transactions related to the digital security token, and linked back to the security token blockchain layer to update the status of the digital security token upon change of ownership.

7. The system of claim 1 wherein the digital security token is linked to a digitized image and/or data of an original security in paper form with cryptographic hash, or linked to electronic data stipulated on an original security with cryptographic hash to provide verification of authenticity and integrity.

8. The system of claim 1 wherein the authentication key is an encrypted encapsulation of the private key linked to the user identifier and the password.

9. The system of claim 4 wherein the authentication key is an instance and is continuously scrambled using a physical random number generator, wherein the system can retrieve the private key by decryption of the authentication key using the user password and one-time password, the private key or the password itself not being stored in the system.

10. The system of claim 1 wherein the identification blockchain layer stores a KYC identifier linked to a user identifier such that no personal information is stored throughout the entire system, wherein the KYC identifier can be referenced to external KYC/AML data stored outside of the system.

11. The system of claim 1 wherein the identification blockchain layer, the security token blockchain layer, and the trade history blockchain layer are interconnected through unique identifiers without storing or revealing any personal information.

12. A non-transitory computer readable medium with executable instructions for causing one or more processors to: at an identification blockchain layer, receive a user identifier and a user password; generate a private key; encrypt the private key into an instance of an authentication key using the password; and store a record of the user identifier and the authentication key, the record not storing any personal information, the private key or the password, the record linking the user identifier to a KYC identifier; receive a recovery request with the KYC identifier and retrieve the user identifier using the KYC identifier; at a security token blockchain layer, receive the user identifier, ownership data indicating a digital security token, a hash for the digital security token, and data indicating the state of the security token; generate a digital security token identifier, and store a record of the digital security token indicating the digital security token identifier, a state, and the ownership data without storing any personal information; and at a trade history blockchain layer, receive a transaction request from a security exchange, the transaction request linked to transaction data indicating the digital security token identifier, a buyer identifier, and seller identifier, wherein the buyer or the seller is linked to the user identifier; and store a record for the transaction data upon verification, the record not storing any personal information, the trade history blockchain layer configured to verify the digital security token identifier with the security token blockchain layer and verify the user identifier with the identification blockchain layer; at the security token blockchain layer, retrieve the record of the digital security token identifier using the user identifier; update the data indicating the state of the security token to inactive; issue a new digital security token having a new digital security token identifier; generate a new record of the new digital security token indicating the digital security token identifier, a state, and the ownership data without storing any personal information; and at the trade history blockchain layer, update the record for the transaction data with the new digital security token.

13. The computer readable medium of claim 12 wherein the identification blockchain layer is configured to generate a new record with the user identifier and a new authentication key, the new authentication key generated by encrypting a new private key using the password.

14. The computer readable medium of claim 12 wherein the authentication key is split into a plurality of portions.

15. The computer readable medium of claim 12 wherein the trade history blockchain layer receives the transaction request and calls the identification blockchain layer to retrieve the authentication key with the user identifier, decrypt the authentication key with the password to retrieve the private key and generate a signature to encrypt and authenticate the record for the transaction data.

16. The computer readable medium of claim 12 wherein the buyer is linked to a user identifier and the seller is linked to another user identifier, wherein the security token blockchain layer can process an ownership transaction request indicating the user identifier, the security token blockchain layer providing verification of the ownership status of the digital security token attached to the user identifier, verification of the active status of the digital security token, the user identifier linked to the identification blockchain layer providing login authentication, signing of transactions, verification of the active KYC/AML status associated with the user identifier, verification of transaction eligibility between the buyer and seller against a whitelist, the user identifier linked to the trade history blockchain layer storing a record of all transactions related to the digital security token, and linked back to the security token blockchain layer to update the status of the digital security token upon change of ownership.

17. The computer readable medium of claim 12 wherein the digital security token is linked to a digitized image and/or data of an original security in paper form with cryptographic hash, or linked to electronic data stipulated on an original security with cryptographic hash to provide verification of authenticity and integrity.

18. The computer readable medium of claim 12 wherein the authentication key is an encrypted encapsulation of the private key linked to the user identifier and the password.

19. The computer readable medium of claim 12 wherein the authentication key is an instance and is continuously scrambled using a physical random number generator, wherein the system can retrieve the private key by decryption of the authentication key using the user password and one-time password, the private key or the password itself not being stored in the system.

20. The computer readable medium of claim 12 wherein the identification blockchain layer stores a KYC identifier linked to a user identifier such that no personal information is stored throughout the entire system, wherein the KYC identifier can be referenced to external KYC/AML data stored outside of the system.

21. The computer readable medium of claim 12 wherein the identification blockchain layer, the security token blockchain layer, and the trade history blockchain layer are interconnected through unique identifiers without storing or revealing any personal information.

22. A system for digital security tokens having code to enable utility features comprising: a server or network of servers having non-transitory computer readable storage medium with executable instructions for causing one or more processors to configure: an identification blockchain layer for receiving a user identifier, a user password, KYC identifier and KYC/AML state, generating a private key; encrypting the private key into an instance of an authentication key using the password and a random one-time code, and storing a record of the user identifier and the authentication key without storing any personal information, the private key or the password; a security token blockchain layer for receiving a user identifier, ownership data indicating a digital security token, a hash for the digital security token, and data indicating the state of the security token, executing smart contract code to enable utility features of a digital security token, generating a digital security token identifier, and storing a record of the digital security token identifier, a state, and the ownership data without storing any personal information; and a trade history blockchain layer for receiving a transaction request from a security exchange, the transaction request linked to transaction data indicating the digital security token identifier, a buyer identifier, and seller identifier, wherein the buyer or the seller is linked to the user identifier, and storing a record for the transaction data upon verification without storing any personal information, the trade history blockchain layer configured to verify the digital security token identifier with the security token blockchain layer and verify the user identifier with the identification blockchain layer.

23. The system of claim 22 wherein the buyer is linked to a user identifier and the seller is linked to another user identifier, wherein the security token blockchain layer can process an ownership transaction request indicating the user identifier, the security token blockchain layer providing verification of the ownership status of the digital security token attached to the user identifier, verification of the active status of the digital security token, execution of smart contract code to enable utility features of the digital security token, the hash for the digital security token, the user identifier linked to the identification blockchain layer providing login authentication, signing of transactions, verification of the active KYC/AML status associated with the user identifier, verification of transaction eligibility between the buyer and seller against a whitelist, the user identifier linked to the trade history blockchain layer storing a record of all transactions related to the digital security token, and linked back to the security token blockchain layer to update the status of the digital security token upon change of ownership.

24. The system of claim 22 wherein the digital security token is linked to a digitized image and/or data of an original security in paper form with cryptographic hash, or linked to electronic data stipulated on an original security with cryptographic hash to provide verification of authenticity and integrity.

25. The system of claim 22 wherein the authentication key is an encrypted encapsulation of the private key linked to the user identifier and the password.

26. The system of claim 25 wherein the authentication key is an instance and is continuously scrambled using a physical random number generator, wherein the system can retrieve the private key by decryption of the authentication key using the user password and one-time password, the private key or the password itself not being stored in the system.

27. The system of claim 22 wherein the identification blockchain layer stores a KYC identifier linked to a user identifier such that no personal information is stored throughout the entire system, wherein the KYC identifier can be referenced to external KYC/AML data stored outside of the system.

28. The system of claim 22 wherein the identification blockchain layer, the security token blockchain layer, and the trade history blockchain layer are interconnected through unique identifiers without storing or revealing any personal information.

29. A process for digital security tokens comprising at an identification blockchain layer, receiving a user identifier and a user password; generating a private key using a Private Key Generation module residing in secure hardware element; encrypting the private key into an instance of an authentication key using the password; and storing a record of the user identifier and the authentication key, the record not storing any personal information, the private key or the password, the record linking the user identifier to a KYC identifier; receiving a recovery request with the KYC identifier and retrieve the user identifier using the KYC identifier; retrieve a record of the digital security token identifier using the user identifier; update the data indicating a state of the security token to inactive; issue a new digital security token having a new digital security token identifier; generate a new record of the new digital security token indicating the digital security token identifier, a state, and the ownership data without storing any personal information; and update the record for the transaction data with the new digital security token.

30. The process of claim 29, wherein the authentication key is generated during onboarding using a dedicated identification layer blockchain, the dedicated identification layer blockchain storing the KYC identifier and the record linking the user identifier to the KYC identifier, the record including at least two computed parameters, lu and Ku, Lu being a hash of the user identifier, and Ku being a hash of the private key, a password and a salt.