Malware(for “malicious software”) is the term for software that is designed to act on a computer in ways concealed from and unwanted by the computer’s user. Viruses, worms, and spyware are common types of malware. (Virusis sometimes used synonymously withmalware, but we will use it in the narrower sense in which it refers to only a particular kind of malware.) Malware code need not be natively executable object code; it could as well be interpreted code such as a script or an executable macro such as those used by Microsoft Word.
Virusesandwormsare characterized by the ability to make and spread copies of themselves; the difference between them is that a worm is a complete program that replicates itself, while a virus is a bit of code that is inserted (and inserts copies of itself) into another piece of software or a file, so that it is executed as part of the execution of that piece of software or as a result of opening the file. Viruses and worms typically cause problems such as consuming network bandwidth as mere side effects of attempting to spread copies of themselves. Even worse, they can also deliberately damage a system or undermine its security in various ways. They could, for example, install abackdoor—software that allows remote access to the system without the normal authentication. This could lead to a firewall exposing a service that should be providing its own authentication procedures but has been undermined by a backdoor.
Spyware is software that, without authorization, collects and transmits private information about a computer system or its users. Usually spyware is secretly embedded in an otherwise useful program and is spread by users deliberately installing copies. The problem for firewalls is that the transmission of the private information looks like legitimate communication.
A natural question to ask is whether firewalls (or cryptographic security) could keep malware out of a sys- tem in the first place. Most malware is indeed transmitted via networks, although it may also be transmitted via portable storage devices such as CDs and memory sticks. Certainly this is one argument in favor of the
“block everything not explicitly allowed” approach taken by many administrators in their firewall configu- rations.
One approach that is used to detect malware is to search for segments of code from known malware, some- times called asignature. This approach has its own challenges, as cleverly designed malware can tweak its representation in various ways. There is also a potential impact on network performance to perform such detailed inspection of data entering a network. Cryptographic security cannot eliminate the problem either, although it does provide a means to authenticate the originator of a piece of software and detect any tampering, such as when a virus inserts a copy of itself.
Related to firewalls are systems known asintrusion detection systems(IDS) andintrusion prevention systems (IPS). These systems try to look for anomalous activity, such as an unusually large amount of traffic targeting a given host or port number, for example, and generate alarms for network managers or perhaps even take direct action to limit a possible attack. While there are commercial products in this space today, it is still a developing field.
organization controls. It’s easy to be distracted by all the hype, but a blockchain is essentially a decentralized log (ledger) that anyone can write a “fact” to, and later prove to the world that that fact was recorded.
Blockstack is an open source implementation of a decentralized platform, including the blockchain, but more interestingly, it has been used to implement a self-sovereign identity service for Internet applications.
A self-sovereign identity service is a type of identity service that isadministratively decentralized: it has no distinct service operator, and no single principal can control who can create an identity and who cannot.
Blockstack uses a commodity public blockchain to build a replicated identity database log. When this database log is replayed by a Blockstack node, it produces the same view of all identities in the system as every other Blockstack node reading the same view of the underlying blockchain. Anyone can register an identity in Blockstack by appending to the blockchain.
Instead of requiring users to place trust in a distinct set of identity providers, Blockstack’s identity protocol instead asks users to trust that the majority of the decision-making nodes in the blockchain (calledminers) will preserve the order of writes (calledtransactions). The underlying blockchain provides a cryptocurrency to incentivize miners to do this. Under normal operation, miners stand to earn the most cryptocurrency by participating honestly. This allows Blockstack’s database log to remain secure against tampering without a distinct service operator. An adversary who wishes to tamper with the log must compete against the majority of miners to produce an alternative transaction history in the underlying blockchain that the blockchain peer network will accept as the canonical write history.
The protocol for reading and appending to the Blockstack identity database log operates at a logical layer above the blockchain. Blockchain transactions are data frames for identity database log entries. A client appends to the identity database log by sending a blockchain transaction that embeds the database log entry, and a client reads the log back by extracting the log entries from blockchain transactions in the blockchain- given order. This makes it possible to implement the database log “on top” of any blockchain.
Identities in Blockstack are distinguished by user-chosen names. Blockstack’s identity protocol binds a name to a public key and to somerouting state(described below). It ensures that names are globally unique by assigning them on a first-come first-serve basis.
Names are registered in a two-step process—one to bind the client’s public key to thesalted hash of the name, and one to reveal the name itself. The two-step process is necessary to prevent front-running—only the client that signed the name hash may reveal the name, and only the client that calculated the salted hash can reveal the preimage. Once a name is registered, only the owner of the name’s private key can transfer or revoke the name, or update its routing state.
Each name in Blockstack has an associated piece of routing state that contains one or more URLs that point to where the user’s identity information can be found online. This data is too big and expensive to store on the blockchain directly, so instead Blockstack implements a layer of indirection: the hash of the routing state is written to the identity database log, and Blockstack peers implement a gossip network for disseminating and authenticating the routing state. Each peer maintains a full copy of the routing state.
Putting it all together, Figure 8.21shows how resolving a name to its corresponding identity state works.
Given a name, a client first queries a Blockstack peer for the corresponding public key and routing state (Step 1). Once it has the routing state, the client obtains the identity data by resolving the URL(s) contained within it and authenticates the identity information by verifying that it is signed by the name’s public key (Step 2).
Broader Perspective
Figure 8.21.: Decentralized identity management built on a blockchain foundation.
To continue reading about the cloudification of the Internet, seePerspective: The Cloud is the New Internet.
To learn more about Blockstack and decentralizing the Internet, we recommend:Blockstack: A New Internet for Decentralized Applications, October 2017.