A long word about security….
The revolutionary Elastos Smart Web Scheme is the most secure practice currently known on the planet to prevent unauthorised access to data, fraud, man-in-the-middle, denial of service, device masquerading and other attacks. The backbones for us in the Elastos system are threefold: Firstly the use of Blockchains (in the format of “SideChains”) to allow a decentralised identification system, secondly was the use of Carrier 2 to provide ultra-secure, decentralised business networking for the applications we are developing, and thirdly a Sidechain enabling ELA/Ethereum Smart Contracts that we use to “anchor” successive Merkle Roots to an immutable medium (the Blockchain). Referring to the following article on ‘Carrier 2’ will reveal the nature of these plans.
Around 2000 the Chinese Government recognised the same problem as everyone: the inherent insecurity of the internet, despite “patches” in so many ways to close security holes.
They funded the development of what eventually became the Elastos Smart Web System. But it was not until 2008 that there was developed a secure and trustworthy format for storage of all the information required by the developing Smart Web System.
Until that point there would have been no more reason to trust the Chinese People than anyone else to not corrupt or otherwise tamper with database information regarding the Smart Web System or something similar. In the Smart Web System, every person, every one of the components in devices, each application installed on the device, and any other entities existing and associated with the device, when a device registers with Elastos, are also registered with unique IDs at the same time, and a system of always being able to assure the identity of an originator of a system request (an onboard application for example) is maintained.
This forms a basis to remove any external, unintended, unauthorised or harmful players from communications over the net and internally between apps, etc. This micro-identity system works perfectly to ensure no external (or internal) threats occur. The identification system is automated and can not be tampered with by any individual, as it is recorded on a blockchain.
It is in the nature of a truly Distributed BlockChain that you would have to have personal/gang control over 33% of mining devices (see BlockChains), at once, across an entire BlockChain, globally, to effect a change which could be fraudulent. This would not be impossible, without the Elastos Trusted Computing Hardware Enhancement as a requirement for all Mining Computers that participate. (Please refer to Elastos Enterprise Strength Block Chains).
The entirety of the Elastos code base is publicly verifiable open source code (100%).
The second component of the Elastos Framework ensures communication of data of any sort between Elastos-registered users &/or devices and sites on the internet is safe, private and secure. It is called the Elastos P2P Carrier Network. The Carrier Network cooperates intimately with the Elastos “Runtime” onboard your device to ensure security whilst providing a web-socketless means of connecting to external internet sites allowed by your app (such as a bank or your company database), between users and between devices.
However an incident has occurred involving the Elastos Foundation which prevented the Carrier 2 Project from running to completion. The Project has been left poorly documented and incomplete. Hence we turned towards “jvm-libp2p”, another Open Source project which is complete, thoroughly documented and actively maintained. Libp2p is now providing us with the entire DHT network needed for us to operate. The network includes the most modern protocols and systems, such as QUIC and HTTP/3, which we are merging with our Edge Communication system of choice, gRPC/Protobufs. This system takes the place of Elastos’ Carrier 2. The other 2 pillars of Elastos are still in use by us.
This means processes occurring within your device and processes requiring communication between Elastos-Registered Devices are entirely safe. An Elastos DApp (or Distributed Application) protects all registered users, whilst keeping all players honest (which is in the nature of a BlockChain – refer to the origins of BitCoin’s BlockChain). In this way, now with jvm-libp2p, the entire Elastos network of people, devices (and ‘Internet of Things’ components) is security-guaranteed.
This quote may enlighten: “While the Bitcoin blockchain does provide tremendous hash power – thus making its network extremely expensive and difficult to corral – it is still technically vulnerable to “33%” attacks, as is the nature of the standalone Proof of Work (PoW ) consensus algorithm.To address the potentiality of such an event, Elastos Blockchains (as opposed to the defunct Carrier System) employs Delegated Proof of Stake (DPoS) in order to install an additional layer of decentralization through its electoral structure. In a standard DPoS consensus algorithm, token holders democratically elect a number of nodes that produce an and validate blocks on the network. In this system, token holders use their voting power to elect nodes that they deem honest to serve the blockchain. For Elastos, the task of producing blocks is conducted by merge-miners, so DPoS nodes serve to officially validate the incoming blocks that have been solved via AuxPoW .As such, DPoS provides an additional layer of security that can filter out faulty blocks in the event that a rogue entity consolidates 33% of Bitcoin’s hashpower.” The other fork to this security guarantee was mentioned above (the Hardware Security Enhancement Device). ITOTCCA is currently working on using the levels of security inherent in the AuxPoW method and the enhancement device to help guarantee the consistency of databases.
Fraud:
There remains, however a threat which plagues Enterprises. It is the internal threat posed by Fraud, including the threat from employees of our own or other organisations and contractors as database administrators, as well as any Hackers who manage to gain internal access to a system. The criminal actions of a person or people otherwise authorised to use an ordering and financial system may be detected and virtually eliminated by imposing certain restrictions, checks and balances in a system. Thus organisations use Internal Auditing to verify transactions, in particular their appropriateness and authenticity. However it has still been the domain of certain Technical Employees and System Administrators to have access to the entire database (Superusers).
The use of BlockChains, an idea originating with Bitcoin, the “crypto-currency”, removes the possibility of anyone at all editing the blockchain of transactions on the “Blocks”. However a financial transaction journal (for example) running on a BlockChain is connected to a database which would not, ordinarily, be immutable. We are following a lead generated by IBM, India, such that our database installation acts like a traditional Blockchain, except large quantities of Data can still be stored, unlike the case with Blockchains, in a Trust-Assured Database system comprising individual Member Class servers. Our systems are designed so that you have to perform any corrections, not by editing records, which would show in automated daily database-blockchain consistency assessments as a targetable problem, but via the normal (internally and externally auditable) accounting processes accessed in the DApp and recorded on the blockchain as a correcting transaction – fully visible.
Elastos is a BlockChain-Based DApp System. A DApp is a Distributed Application (there is strictly no central webserver – at least not for the BlockChain – it’s all on the Light, Regular Nodes and Super Nodes (servers) to which your device (a “Light” node) connects). There is no central server. All nodes are keeping each other honest, by design.
IT/OT Chain & Cloud Australia is designing a novel Architecture with Methods inspired by research at IBM, India. Our Member Class servers are operated by member class Consortia (of the classes’ member companies) and our design allows Trust to exist amongst distrusting companies, assured by the operation of the system itself, such that every Member Class server is keeping every other one honest by design, along the lines of the traditional Blockchain approach, yet allowing unlimited quantities of data to be stored.
We are further motivated to ensure security, by noting that ordinarily the Byzantine Fault Tolerant transaction Replication & Ordering system will fail if there exists a “gang” of > 33% of the Database node operators and they enact fraudulent transactions &/or withhold them. We are developing a system that records (non-strategic) traces of every database transaction, grouped into Slabs of 24 Blocks each with an average of 1024 Transactions per Block. By recording all traces on the metadata database, and “anchoring” one calculated “Merkle Root”, per Slab, to the Elastos/Ethereum Sidechain, we obtain a source of historical truth about the database against which to compare the penultimate state of the database after every 6 Checkpointing Cycles (Checkpointing occurs after every 4 Transaction Blocks have been committed). This would amount to Better-than-Byzantine Fault Tolerance in a database-node cluster situation.
We call our system 
“ChubbyChecker“. Chubby examines each transaction trace from 29 different angles to determine the validity of the database states, as determined by the demand for internal and external consistency.
The sense in which the term “Automated Trust” could be used here, should be taken to indicate that Trust in the Owners and Operators of a Database System can be guaranteed, given that the initial Coding and Development process is Transparent to all Business Customers of the developers/SaaS (Software as a Service) providers. This is because the Business Customers (with sound Governance) actually Operate their own Member Class servers under leases from the SaaS providers. As operators, they are expected to look after their own IT interests, but they are not expected to need to Trust any Operators in the system of Database server nodes. The coded system enforces Trustworthiness in a strict way, and programmatically, amongst all operational parties. The old style of Trusting one or several Database Superusers with ultimate control can be over.
Nevertheless, the committing of a fraudulent act by a corps of over 33% of the Member Class “sites” in a Network, acting together, is possible. Such an act would be notified to all stakeholders, including all Member companies of all Member “Classes” on the “offended” installation, immediately upon the next consistency check against the Elastos Blockchains, scheduled to occur at every 6 Database Block Checkpoints. The Blockchains will have been recording traces continuously, forming an ultimately reliable audit trail, which can be compared against the databases by starting from the last clean block on the database and obtaining a log of the Database Operations from that point forward. If the lists of committed transactions (together with their Block Orderings) are not consistent, an Alarm is Broadcast to all Stakeholders, and the SaaS provider’s Contingency Plan is implemented immediately.The SaaS provider’s own Governance obviously requires a sound and complete Contingency Plan for such Breaches, extending to specifying Member Companies’ contractual duties to have and understand their own External Data Inconsistency Contingency Plan. It is also necessary to detect false positive indications before taking further action.
With respect to the fact that Database security operations always require at least “READ” access to some of the technical fields of a database, we are proposing to encrypt the Customer data fields that are necessary for our security system to operate with our own public key. Thus even though an operator has access to the tables of customers, all data is obscured, including all confidential and private data. The data we operate on that we need to be able to read, is finally re-encrypted using the customer’s public key, prior to storage.
In all cases of a Data Inconsistency Alarm being broadcast, a Root Cause Analysis is required, where the SaaS provider is the responsible party, in consultation with all affected Members.
However, some Fraudulent acts committed by employees of Member companies, cannot be prevented by the SaaS provider, nor detected (in the absence of an Audit of the Company’s Accounts). That is, the responsibility for the majority of Trust situations with respect to Member company employees, falls to the employer, not the SaaS provider. This is because it is quite possible to present an appearance of externally and internally consistent and Trustworthy transactions while indulging in Fraud or embezzlement. External Consistency is not the same as Internal Consistency (in this sense, meaning within your company’s accounts). Internal Auditing and a sound Culture at the company can assist. The contribution that the SaaS provider can make here is by providing the immutable and non-repudiable (client-signed) Blockchain and Database logs and records. All transactions (and not just financial ones) are accompanied by the Digital signature of the client (person), or at least of a device owned, and registered by them on the Elastos System.
In summary we are guaranteeing “External Consistency”, ie external to Member companies.
Please refer to The Bucordo Project on this site.
IT/OT Chain & Cloud Australia also employs other standard methods such as ensuring separation of Order and Requisitions functions from Accounts Payable functions, as well as other safeguards against internal fraud based in a Role/User system.
We change our auditor regularly.
Distributed Non-Relational Bulk Data Storage (with 
)
Online Relational Information Storage (with PostgreSQL. 
)
In general, Off-Device Data Storage itself and Cloud Operations, in combination with Device-Based Blockchains, are neither particularly restrictive in terms of (authorised) accessibility, nor expensive. It is, in fact, very safe and secure when done properly. In terms of file storage, the unique “hash” signature (.. the ‘signature’ only, not the volume of data) of each data file (eg Documents, Images, Audio, Video), is recorded (together with the other auditable data) on the Blockchain (Sidechain), and may be compared to the hash computed from the file, whenever retrieved, to check for tampering. The actual data files are stored on a distributed network of Elastos-enabled IPFS community-supplied Servers (where providers of Disk Space are rewarded in ELA), a business expense of ours.
If you are governed by laws or externally or internally-imposed regulations about where you may store flat file data, you would probably choose an Elastos-sponsored connection to a nationally based Cloudserver storage system.
Nevertheless the main transactional database needs of enterprises are provided by a central cloud based installation accessed via the “socketless” Elastos P2P Carrier Network. We employ Postgres databases. Because it is true that Database Superusers in our organisation could conceivably corrupt stored data, we use automated sidechain-based checks for consistency on the state of the database, comparing end-of-previous period-state to end-of-current period-state. The difference must be computed as consistent with the immutable evidence on the sidechain. The Checkpointing cycle itself repeats at every 4 Block Commits, with the Ultimate Check occurring every 6 Checkpoints, ie many times daily. Automated alarm communication occurs upon faults being found. We also log every access to the database of any type, so all database admins’ and superusers’ actions are audited. In addition, the operational principles programmatically designed-into our cloud installations prevent dishonesty (seen as “inconsistency”) in our databases.
Basic Principle:
“One of the keys to Computer Security is to assume that every connecting device is potentially hostile to your system.”
ITOTCCA undergoes full and independent database and file storage system Security Audits yearly, as well as many daily consistency tests of the database against the audit trails on the Elastos/Ethereum Blockchain, with alarms reported securely, reliably and automatically by machine to our Board and simultaneously to all other stakeholders (ie to all member companies, on the offended installation(s), in the first place). Our databases are backed up every 30 minutes with copies stored at multiple sites, and not automatically connectable, which means that in the event of a data crisis (very unlikely), the latest “clean” backup can be manually restored and the system written forward from that point by re-running (de-corrupted) ‘WAL’ logs (Write Ahead Logs) to the latest ‘WAL’ file. This would restore the database to the backup just before the point of take down, so possibly up to 30 minutes work could be lost, plus the time it takes us to isolate and correct the corruption. Therefore we remain vigilant but confident.
With all our security and anti-fraud efforts combined, we offer GOOD (Guaranteed Ownership Of Data) to your organisation as a promise that we will protect and hold safe all your data and transactions.
We develop on Ubuntu Linux Machines (hosts) with Alpine Linux containers (on Docker and Kubernetes, on the hosts) for compact image size. We employ openSUSE Linux virtual machines.
 |
 |
Haskell WebServers are good!
and we develop for iOS on Apple Mac: For the iOS environment of Front End DApps
Our standard meets or exceeds ISO 27001 and ISO 27002 (Information Security Management Systems, including Best Practice Recommendations).
Thanks to:
Elastos Global Network Operating System, (since 2003) .. “Agnostic” to Device Operating System Brand
the Unix Device Operating System (since it began to escape from the International Criminal (ask about the history of the Anaconda Copper Mine in Chile) AT&T’s Bell Laboratories in the early 1970’s); Ken Thompson, Dennis Ritchie and the ‘C’ programming language.
and the Open Software Foundation (1984 – 1996), whose members helped set it free
and The creators of O.O.P. (Object Oriented Programming – from late 1950’s), especially Bjarne Stroustrup (from 1979) the inventor of C++, which saved the developers’ world.
and the IBM and Intel Companies for introducing the x86 PC Architecture.
also, Apple Inc, particularly for the quality .. and for switching to a Unix Operating System (based on a fork of the open source 386BSD operating system, which is built on Objective-C ) for their own computers, for some time using Intel Chips (although this is now changing).
the Free Software Foundation (since 1985)
(not forgetting) .. Google & the Android developers, Ken Thompson, Google and the GO developers & Brendan Eich, Google and the V8 Javascript Engine developers & Google and the Kubernetes developers & Google and the TensorFlow developers. Also James Gosling and the Java! developers.
also, of course Linus Torvalds,
who originally licensed and studied an educational version of the Unix Operating System for PC’s (or “Microcomputers”) called “Minix” from Prof Andrew S Tanenbaum in the form of a book with included source code – on Floppy Disks – (published by Prentice Hall) for $US69, based on the 1980’s series IBM/Intel-XT Personal Computer Architecture. (Unix, more a set of Standards now than “code”, was written originally for Minicomputers and Mainframes in networked multi-user environments, but there is no reason it can’t run – when the source code is written to the Unix Standards and compiled for the IBM/Intel Architecture – in multi-user fashion on a PC, which is the same class of electronic device as any other – non ‘Quantum !! ‘ – computer). On January 5, 1991 he purchased an Intel 80386-based (“80386” CPU or processor) IBM PC XT/AT “clone” computer before obtaining his MINIX copy, which in turn enabled him to begin work on Linux. He commenced work on Linux in mid-March, 1991 (see below “Tanenbaum” link).
MINIX:
Relationship with Linux
Early influence
“…The design principles Tanenbaum applied to MINIX greatly influenced the design decisions Linus Torvalds applied in the creation of the Linux kernel…. Torvalds used and appreciated MINIX, but his design deviated from the MINIX architecture in significant ways, most notably by employing a monolithic kernel instead of a microkernel. This was disapproved of by Tanenbaum in the Tanenbaum–Torvalds debate. Tanenbaum explained again his rationale for using a microkernel in May 2006…” (Wikipedia)
[ Nevertheless Tanenbaum (see the above link) admits that the demand for performance, in terms of computational process-speeds, but also in terms of speed in progress of the development effort, from users of Linux, outweighed the capacity of a microkernel system and militated in favour of developing a monolithic kernel, for practical reasons. The reasons for Tanenbaum’s preference for a “microkernel” lie in its security advantages. -Ed.]
“..Early Linux kernel development was done on a MINIX host system, which led to early Linux inheriting various features from MINIX, such as the MINIX file system.
Samizdat claims.
In May 2004, Kenneth Brown of the Alexis de Tocqueville Institution made the accusation that major parts of the Linux kernel had been copied from the MINIX codebase, in a book called Samizdat. These accusations were rebutted universally—most prominently by Andrew Tanenbaum himself, who strongly criticised Kenneth Brown and published a long rebuttal on his own personal Web site, also pointing out that Brown was funded by Microsoft.
Licensing
At the time of its original development, the license for MINIX was considered to be rather liberal. Its licensing fee was very small ($69) compared to those of other operating systems. Although Tanenbaum wished for MINIX to be as accessible as possible to students, his publisher was not prepared to offer material (such as the source code) that could be copied freely, so a restrictive license requiring a nominal fee (included in the price of Tanenbaum’s book) was applied as a compromise. This prevented the use of MINIX as the basis for a freely distributed software system.
When free and open-source Unix-like operating systems such as Linux and 386BSD (386BSD is an ancestor of Apple’s MacOSX -Ed.) became available in the early 1990s, many volunteer software developers abandoned MINIX in favor of these. In April 2000, MINIX became free/open source software under a permissive free software license, but by this time other operating systems had surpassed its capabilities, and it remained primarily an operating system for students and hobbyists….” Wikipedia (see “MINIX” link above).
Linus went on to design and build the ubiquitous version control system known as “git”
+ A strong ‘Thank You’ to the Unix/Linux open-source ecosystem (since 1991), including
All Contributors, under the various open source and free software licences, past and present.
Also, many thanks to: Rong Chen and Elastos
In 2000, Rong Chen, a senior alumnus of Tsinghua University’s Computer Science department, returns to China from Microsoft USA and begins research and development for the first-generation Elastos network Operating System.
In 2003, Rong Chen was received by Jin-Tao Hu, the former CPC General Secretary.
In 2006, Rong Chen completed the kernel and graphics systems.
In 2007, Rong Chen built a complete smartphone and massively produced it.
In 2009, China Unicom used Elastos’ middleware as a fertile phone operating system framework.
In 2013, Foxconn invests in the Elastos open source project to build a distributed, cross-internet industrial Internet of Things and a smart home network operating system.
In May 2017, Rong Chen co-founded the Elastos Foundation with Feng Han to support Elastos – a blockchain-driven Internet project, attempting to create a new digital smart economy model that turns numbers into wealth.
In 2017, Sunny Feng Han and Ji-Han Wu started running the Bitcoin Investment Elastos Blockchain Community and an alliance with Bitmain and NEO started to take shape.
