BM: Why does the security of every company depend on the blockchain?

Written in front: The author of this article is EOS founder Daniel Larimer. In his article, he analyzed the deficiencies of the infrastructure and design of traditional databases and other databases and pointed out that blockchain is the best solution: Open blockchain frameworks such as EOSIO free developers from having to build secure applications. The program recreates the "database" because all users sign their actions with a private key for traceability and verification. One goal of B1 in the future is to add tools and interfaces to promote the process of deploying business on the blockchain similar to (or even simpler) than deploying business on the traditional Internet.

Traditional web application infrastructure is designed with security as an afterthought, and for the past 25 years, many companies have been trying to patch up a fundamentally insecure architecture. This architecture is designed to presume that the server can be trusted and protected, but years of experience tell us that no server is secure, let alone an internal attack. In other words, the server is basically centralized.

We used to think that the "problem" was the connection between the user and the server, so we introduced SSL and HTTPS. But then we discovered that hackers would destroy the database and steal passwords. So we started storing password hashes, but later we discovered that hackers would forcibly crack passwords after stealing the hashes. We then introduced a password switch mechanism to change passwords during brute force attacks, and many more.

• Cryptocurrency overwhelming, Trump releases fiscal 2021 budget to increase regulation
• In the face of the epidemic, how can blockchain improve the ability to govern according to law?
• Destiny and reincarnation: the moment of Bitcoin's production reduction

To protect servers and databases, businesses need to spend billions of dollars, and despite all the efforts, there is still no easy way to review the system and ensure that the business operates as expected.

Block.one is building blockchain software to keep databases and user accounts secure from unauthorized access and unexplained modifications. With the blockchain, users can use highly secure private keys, which are stored in secure hardware and are used to sign each user interaction instead of simply authenticating the server connection. The blockchain creates an immutable record, establishing an absolute and deterministic sequence for receiving user input, and smart contracts provide deterministic business logic to ensure consistency across all systems.

The future Block.one is eliminating passwords and expensive audits, saving businesses billions of dollars, preventing identity theft, and providing greater reliability and auditability.

For years, I have thought that every multi-user website could benefit from a blockchain backend. Unlike many people's perceptions, the blockchain does not have to be a slow, inefficient database, nor does it have to operate on an anti-censorship, open basis. Blockchain can provide important improvements in terms of security, auditing capabilities, transparency, and integrity of business processes.Even if the blockchain is operated entirely by the company itself, everything in it will not be made public. This article aims to reveal the true value of blockchain in the corporate environment and to point the way for the development of the blockchain industry.

Common misconceptions

In the blockchain industry, many people believe that blockchain can only create advantages when it connects participants who do not trust each other. They believe that traditional database technology can already do all the work needed to secure the business. In other words, they believe that traditional database replication and "data integrity" guarantees are sufficient. In the process, they either ignored or ignored the completely different security and integrity guarantees provided by the blockchain:

Commitment to the global event sequence

2. Deterministic execution of business logic

3. Tight coupling of business logic and data integrity

4. Eliminate the password

In traditional business application architecture, business logic is separate from the database. There is usually an application server, such as Node.js or J2EE, which provides passwords for modifying the database. The role of the Node.js server is to authenticate users through passwords or multi-factor authentication mechanisms. Once the application server authenticates the user, it issues a session token that is used to authenticate future user interactions until a timeout or some element of the session, such as the IP, changes.

Obviously, this traditional design performs all database operations with a single login / password managed by the application server. Through the end use, the application server is responsible for deploying the authentication mechanism. Obviously, there are usually multiple users who can access the username and password. Database administrators can assign and revoke credentials to many different application servers or individuals.

Advanced systems ensure that in a scale-out system, each application server has its own username and password, and in some cases even public key infrastructure (PKI) and hardware security modules (HSM) can be used. However, even here, the database only authenticates the connection to the application server. To provide an audit log, it must record the entire data flow of a secure connection. However, even this log can only record "read and write operations" requested by the application server, and the application server has lost all the information originally intended by the user.

Auditors reviewing such a system cannot know whether the application server (such as Node.js) follows the correct business logic and whether the identity of the end user is correctly verified. The Node.js process can record user operations into a database, which is convenient for auditors to copy the same calculations, but such records are not immutable, and without independent authentication verification, it is impossible to understand that the end user really authorized a certain behavior.

You can try to record each user's connection, but since users often transmit their passwords over the connection, these records will eventually become a honeypot that leaks user information. More sophisticated systems can encrypt these records so that only auditors can read them.

Assuming the audit log has not been tampered with, the auditor will have to run the same sequence of operations through the application logic to verify that the final database state matches. This means that the application server must be implemented in a deterministic way.

Deterministic calculations are difficult

Although writing deterministic code seems simple, virtually all common computer languages ​​are non-deterministic because they allow developers to access data stored outside the database. It can be something simple, such as a timestamp, memory address, environment variable, IP address, or something more subtle, such as floating-point behavior on hardware or the insertion order of a hash table. In many cases, accessing the memory variables of a long-running application server is sufficient to introduce uncertainty. The action of starting / stopping the application server must be recorded and copied, otherwise every local memory access may be indeterminate during replay.

The truth is that writing deterministic code is a challenge for the best developers who have been trained with common misconceptions and actively looking for non-determinism. The typical enterprise application developer will find it difficult or impractical to write code in a deterministic way.

If we further assume that the application code is deterministic and the application faithfully records user events, then we still face the challenge of tracking the deployed code version. The application is dynamic and frequently updated, so the application code itself must also be part of the database state, and the management and recording of its updates is the same as the security and auditability of user operations. Auditors then need to have copies of all versions of the application server code and replay user input (and restart code) with each version upgrade as needed.

Even though a single application server can operate in a deterministic manner both in terms of installation and deployment, it still encounters a major scalability issue. Only one application server instance can operate on the database. Parallel access can be achieved with complex locks, but even the race conditions on the locks must be recorded and copied, or two instances of the application logic with different local variables may produce indeterminate output.

At this point people may completely give up certainty, but after being absent, certainty will gradually accumulate a large number of deviations in the final data set. Auditors will be forced to use fuzzy logic and approximate matching, and everyone must believe that "fuzzy logic" is good enough.

Of course, to negate all the effort involved in writing and deploying deterministic code, the only thing to do is to have the database administrator modify the database directly without tracking it. In some cases, careful updates to user input logs and status may create two different database states, each of which passes a deterministic test, but still has a different and irreconcilable output. For example, suppose a professor submits a student's grade to F to the system, and then the student can enter the database by hacking or bribing to change his grade and the record submitted by the professor.

Eliminate password

The ultimate goal of any multi-user system that values ​​integrity is to ensure that user input cannot be falsified. The use of username / password or other subjective multi-factor authentication (such as SMS or Google authentication) depends on the server to determine whether the passwords match, or whether the correct SMS code / email link / verification code has been entered. Obviously, this is a huge problem for the integrity of the system, and I will provide a real example to show how bad these systems are.

In 2016, I opened an account on a cryptocurrency exchange, and then this one was hacked, and the hacker stole tens of thousands of dollars in bitcoin. I received a total of 4 emails at the time, the first one was a "password reset" message, and then the other one showed that my password was successfully reset. I then received an email asking to confirm my Bitcoin withdrawal (with code / link). Then I received a notice saying that my withdrawal procedure had been completed.

At first glance, my mailbox seems to be hacked, but this is not possible because I use multi-factor authentication. My mailbox security page shows no unauthorized access. I can also see, because Google will record and display all the IPs and devices that access my mailbox.

In fact, the attacker intercepted the message before it reached my mailbox. The application server cannot know that the email was intercepted, so even if the attacker only has a one-time code generated by the application server, it can still obtain authorization for password reset and withdrawal.

The same vulnerabilities can also be applied to technologies other than SMS or private keys that rely on user control. A truly secure user account is to use a hardware-based private key for all users as their login credentials. In the event that the hardware key is lost, a robust and time-consuming process is used to promote a secure reset.

At this point, the multi-user business application can use the user's private key to sign each user request, record this signed request in a database, and process it with deterministic code. Even this does not provide the integrity that one would expect, because user requests may still be deleted with side effects. Imagine that when a police officer submitted your ticket and all states produced the request, you could hack the police database and delete the request he signed.

At this point, a savvy engineer will claim that every question I ask can be solved by changing the application logic. He's right, a mature application developer can build a relatively secure and auditable system using traditional databases, traditional application servers, and common password primitives. According to the same logic, a savvy engineer can claim that a database is completely unnecessary, and everything should be built directly on the file system. Some engineers may point out that we can write code from scratch and no longer rely on application server frameworks such as Node.js and J2EE, which can improve performance. It's as if everything is made with low-level technology, and we can also design the best performing transistor.

I point to this extreme because it emphasizes the true utility of advanced frameworks in accelerating and protecting the development of new applications. Few people write their own password libraries or algorithms, and the people who write these libraries or algorithms are either experts or have become negative materials when their systems are hacked. The cost of developing / re-developing everything from scratch can make every application more expensive than building on a proven framework.

Advantages of blockchain applications and data servers

Blockchain and EOSIO development frameworks exist so that application developers do not have to re-create "databases" in order to build secure applications. Security and determinism are difficult to achieve, which is why technology is built on a layer of abstract detail. EOSIO combines a deterministic execution environment (WebAssembly) with a fast database in the same process. All user operations are signed by their own private key and recorded in a replicated and distributed database with the ability to make public commitments to the block header.

It's only a matter of time before a framework like EOSIO becomes as powerful and easy to develop as traditional insecure systems. In many ways, the architecture of EOSIO has higher performance than traditional systems, because it places application logic in the same process space as the in-memory database. This creates a deterministic stored procedure.

In the coming years, Block.one's goal is to add tools and interfaces that make deploying enterprise applications on the blockchain as easy (or easier) than deploying similar applications on traditional enterprise application architectures.

Obviously, the adoption of blockchain technology should be a priority for government agencies, listed companies, and businesses with a responsibility to prevent fraud or financial reporting. In my opinion, not using blockchain technology in the next few years is like banks not using SSL. Once the technology is widely used, not using blockchain technology will be considered negligent.

It's time to start. Without fundamental changes to the way applications are built, your business and users will not be secure. With every day of delay, your business is at risk of fraud or hacking.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!