UDC Security Overview

🇬🇧 / 🇷🇺

UDC is the ready-to-deploy solution to launch the centralized blockchain-based payment system (such as CBDC, Central Bank Digital Currency), capable of tokenizing (in a form of tokens ready for smart-contract usage) the currencies, commodities and other assets of real world. It is based on Universa Blockchain technologies; therefore let’s examine the security aspects enforced by Universa Blockchain, as well as the security aspects enforced by UDC solution.

UDC is highly secure against the common external attacks due to being blockchain-based and having the business logic enforced by the smart contracts. Thanks to the Universa Blockchain architecture, all the registered operations/transactions are atomic (“all or nothing”), and most of the “classic” blockchain attack kinds are avoided

In general, using the blockchain (and in particular, using Universa Blockchain specifically) has the following general security benefits:

Typical blockchain attacks repelled by UDC

In UDC, noone can “split the network”

The “textbook” blockchain architecture assumes that the data inconsistency between multiple network nodes (at some specific moment of time) is an expected behaviour. Some of the nodes assume some specific block/transaction valid; but relying on their opinion of the data validity (like, relying that some payment has been successfully received) could be a fatal mistake in case if some other nodes have some conflicting block/transaction which will eventually be included in the blockchain. People have to use empirical (or statistical) methods of trusting a block validity upon the sufficient number of subsequent blocks (“confirmations”) after the block-in-question, assuming that having enough “confirmation” blocks gives a low probability of reverting for this block – there are no exact numbers for “confirmation blocks” though usually, which would be strictly sufficient for a guaranteed block un-revertability. This kind of consistency is usually called “eventual consistency”.

Therefore, the “classic” blockchains can be attacked by having some transaction registered on some (insufficient) number of nodes; if this transaction is noticed by the client (which may assume upon it that, e.g., some shop invoice has been successfully paid). But the network is actually being “split”, and there is a conflicting transaction on other nodes having higher priority to be included in the blockchain (e.g. having better criteria for inclusion) but which also contradicts the first transaction (e.g. uses its money for a totally different transfer). If the first shop mistakenly assumes the first transaction being valid just because it is valid at some moment of time (and maybe even ships the purchased goods) – the first transaction eventually will become revoked/reverted, and the conflicting transaction will eventually be assumed valid. The first shop may keep believing the invoice has been successfully paid – but effectively this payment is reverted, even though having been assumed valid some time before.

Contrary to the classic blockchain approach, Universa Blockchain consistency kind is “immediate consistency” – any attacks based on “reverting the blocks” or “insufficient confirmation blocks” are just impossible: there is no such concept as “confirmation blocks” in Universa Blockchain, and a transaction ever consensually considered valid, won’t unexpectedly start being invalid. If a transaction is successfully registered, it is successfully registered.

In UDC, the transaction history cannot be falsified

Typically for other blockchains, for this attack to succeed one needs to spoof the data on a majority of network nodes. The typical approach for “classic blockchains” is “50% + 1 node” rule (so many nodes should be controlled by the intruder for the successful attack); the Universa Blockchain approach is “90% nodes”, what complicates the attack significantly. The network security against this kind of attack can be scaled to any desired degree by increasing the network size accordingly.

To decrease the risk of mass attack using any 0-day vulnerabilities affecting many nodes at once, the private network nodes can be set up in different datacenters and using the different OS/software version. With this scenario, even if a global OS-affecting 0-day vulnerability is found (like if one more Windows exploit is discovered), the nodes running using other OSes/kernels won’t be affected and won’t allow to spoof the blockchain data.

In UDC, a counterfeit asset issuance is impossible

... because one would have to forge the whole history of token transactions for that.

Every issued and used (in any transactions) token keeps its history, as well as the history of its issuance. The counterfeited token just won’t be accepted by the system, due to every issuance of the token keeps the token properties defining the rules of its usage and the acceptance requirements for the system; in particular, it specifies the multisig keys the issuance should be signed with, to be considered official. One cannot forge just this record, unless changing the transaction history on a significant number of blockchain nodes (90%); therefore only the system key owners (supervisory board) are allowed to issue the tokens.

For an even better level of security of supervisory board (system key owner) operations, the rank of the appropriate multisignature key may be increased significantly. E.g., a new token issuance may require “70 signatures out of 100” or even “2 thousand of 3 thousands”. There are no artificial limitations for multi-sig key components (such as in Bitcoin codebase, that supports up to 3 keys using P2MS scheme and up to 15 keys using P2SH multisig key scheme). Using so high-ranked multisig keys makes better protection against them being stolen; and it is impossible to make a token issuance having insufficient number of signatures – it just will be rejected by the blockchain. Some more details on token issuance procedures: Issuing DC.

A wonderful feature of the system is the capability to replace the issuer keys after the actual issuance; it provides the way to maintain and increase the issuance security level, replacing these keys regularly. The previously issued tokens will support the security level of the new tokens: the smart contract structure grants the supervisory board quorum the rights to replace their own keys, revoking the old ones and introducing the new ones, all the avoiding any changes in the existing tokens. This way, the future security of the existing tokens can be ensured without the need to swap the circulating “digital banknotes” – even the network software upgrade and adding the newer, more secure cryptography algorithms for issuance keys won't need any mandatory actions with the circulating smart contracts, until they are taken out of circulation organically.

In other words, the digital banknotes do not “decay” and can be “refreshed” right in the “owner’s pocket” just through adding the new supervisory board keys.

In UDC, the illegal operations with the tokens are impossible

... because one would have, once again, to forge the whole history of token transactions and alter its very initial definition.

Every operation is signed with either the owner key or a key of some other side authorized for this kind of operations; and all the authorization rules (describing the parties authorized and any conditions of authorization) are defined in the very first, “origin” revision of the smart contract, and cannot be modified in any other way besides their own definition.

Any operation which is not signed by the necessary keys is rejected by the blockchain network. Therefore, to accomplish an illicit operation one has to access these necessary keys; therefore the system security is dependent by the security of keeping the keys.

High-strength cryptographic algorithms and security keys

The asymmetric cryptography and digital signature algorithms used by the system specify the high-strength security keys (inside the system, lies the time-proven RSA algorithm, having no cryptographic vulnerabilities found for 43 years after the initial publication; utilizing the keys 4096 bits and longer, with the possible upgrade to 8192 bits), what provides us years and years of cryptographic security. If necessary, and for better integration with external software and hardware, the system can be transparently updated to support other algorithms (including the elliptic curve based ones).

The key system smart contracts allow to revoke the important system keys at any moment, and create them anew. A reasonable protocol of regular key lifecycle (involving the random-interval key replacement and immediate replacement in case of any possibility of key leak) can ensure the high resistance against key theft or bruteforce.

A very important factor for blockchain systems security is the selection of the prime cryptographic hash function, used for signatures and “fingerprints” of the data blocks (in case of Universa – to uniquely identify the smart contracts and their revisions). To repel the possible scenarios of hash function vulnerability injected yet on the stage of hash function design, Universa/UDC utilizes the unique scheme of hash function utilization: a concatenation of three publicly available, trusted and standardized hash functions, SHA2-512/256, SHA3-256 and “Streebog”:

  • SHA-512/256 – the SHA-2 algorithm family variant, providing the maximum security among all 256-bit variants of the family. Designed by USA National Security Agency (NSA), standardized as:
    • FIPS PUB 180-2, FIPS PUB 180-3, FIPS PUB 180-4 – US State standard since August 2002;
    • CRYPTREC – Japan state standard;
    • NESSIE – European Union standard.
  • SHA3-256 – 256-bit variant of SHA-3 algorithm. Designed by the European cryptography professional team for the NIST hash function competition (2007). Standardized as:
    • FIPS PU B202 – the latest US State standard since August 2015.
  • “Streebog” – 256-bit hash function, designed by Russian FSB together with InfoTeCS JSC. Standardized as:
    • GOST R 34.11-2012 – actual Russian Federation standard since August 2012.

Jointly using the functions of three different cryptographic hash function families, designed by the cryptography teams from different countries, allows to mitigate the risks from possible “algorithm backdoors” in any specific of these hash functions, as well as the risks of vulnerability being discovered in any of them: any vulnerability that makes it simpler to find the collisions in one of the algorithms, won't be applicable to easier found the collisions in the other two. The compound concatenation of the hash functions has the total effective 768 bits of security.

Backdoor protection

The UDC system is built on blockchain smart contracts, therefore any backdoor can exist only in the definitions of these smart contracts. If the smart contracts do not provide some capability – e.g. to execute an extra token issue without the multisig key of the supervisory board – there is no way to get around it. Even if the intruder gets the access to the data of the system stored in the blockchain, they won't be able to do anything having no access to the aforementioned key(s).

The smart contracts are open and declarative in their nature (being the data rather than the program on some programming language), and can be independently audited. The smart contracts are rather brief and compact, so it is rather impossible to “hide” any backdoor inside. Any backdoor in the server or client software, in its turn, is unable to get around the restrictions specified by the smart contract definition. The blockchain network node software can be audited (as well as their implementation being unable to provide any operations over the smart contracts contradicting the the smart contract definition) — the Universa Blockchain network node code is publicly available at Github.

The smart contract registered in the blockchain cannot be altered in any way besides its own definition and specification. Universa/UDC assumes the “deny-by-default” policy: any operations are disallowed by default, and the smart contract designer has to specify any specific permission for the operation to be allowed.

Therefore, the only sensible place for a backdoor could only be the client code constructing and signing the transactions. This is a very limited area which can be audited thoroughly to prevent it.

The developers have no access to the system control keys

All the important system management keys should be created without any developers intervention (or access), by the users themselves and on the user-side equipment. (Besides the keys of the system itself) none of the user keys are available to the server-side software: the server-side receives only the documents that have already been signed. The signature procedure itself is executed on the client side: on the laptops, smartphones and the tables of the end users. If the secret keys are stored in the system, they are being encrypted for long-term storage; the encryption and decryption itself is executed on the client-side equipment too (e.g. on the user’s laptop); neither the key nor the password are ever transmitted over the network or stored anywhere in plain text.

During the initial setup, the network owners create their own access/secret keys (unbeknown to the system developers) and replace the key used for the system bootstrap. The developers do not have access to the newly created management keys, and cannot obtain access to them even if able to control the server-side code.

Therefore the overall security of the system is limited by the security of the management secret key storage (and/or their passwords); in particular by the security of CFO/supervisory board secret key storage. This goes beyond the responsibilities of the UDC software and should be covered by the topics of system regular usage and enforcing the reasonable operating procedures and security practices (e.g. “you should not keep the password written on your credit card or on the on-display sticker”).

Example: counter-measures in case of security breach

Let’s imagine the worst-case and most-destructive scenario: either CFO themselves is the malicious party, or CFO key has been leaked due to insufficient security hygiene. E.g. using the Chinese webcam on top of their PC, and the encrypted key is stored on Windows PC (which, in practice, can already be sufficient for attack even without the camera access, due to Windows often enables the remote attackers to get the full control on the system).

When the operational anomaly is detected and CFO is under suspicion, the supervisory board can revoke the CFO key just by signing the according contract – effectively, dismissing the CFO via this contract (and thus revoking any CFO operational authorizations from CFO’s key). Since this moment, the key cannot be used anymore for any of the operations. After some time, a new CFO will be appointed; the new CFO, using the blockchain data history, can effectively rollback the illicit transactions.

The system can be supplemented with a module to automatically resist some special kinds of operations (e.g. cash withdrawal or bank transfers to the external banks) in case of any suspicion of top management illegal activities.