Blog: February 2019 Archives

Can Everybody Read the US Terrorist Watch List?

After years of claiming that the Terrorist Screening Database is kept secret within the government, we have now learned that the DHS shares it "with more than 1,400 private entities, including hospitals and universities...."

Critics say that the watchlist is wildly overbroad and mismanaged, and that large numbers of people wrongly included on the list suffer routine difficulties and indignities because of their inclusion.

The government's admission comes in a class-action lawsuit filed in federal court in Alexandria by Muslims who say they regularly experience difficulties in travel, financial transactions and interactions with law enforcement because they have been wrongly added to the list.

Of course that is the effect.

We need more transparency into this process. People need a way to challenge their inclusion on the list, and a redress process if they are being falsely accused.

Posted on February 28, 2019 at 6:22 AM24 Comments

"Insider Threat" Detection Software

Notice this bit from an article on the arrest of Christopher Hasson:

It was only after Hasson's arrest last Friday at his workplace that the chilling plans prosecutors assert he was crafting became apparent, detected by an internal Coast Guard program that watches for any "insider threat."

The program identified suspicious computer activity tied to Hasson, prompting the agency's investigative service to launch an investigation last fall, said Lt. Cmdr. Scott McBride, a service spokesman.

Any detection system of this kind is going to have to balance false positives with false negatives. Could it be something as simple as visiting right-wing extremist websites or watching their videos? It just has to be something more sophisticated than researching pressure cookers. I'm glad that Hasson was arrested before he killed anyone rather than after, but I worry that these systems are basically creating thoughtcrime.

Posted on February 27, 2019 at 6:22 AM55 Comments

Attacking Soldiers on Social Media

A research group at NATO's Strategic Communications Center of Excellence catfished soldiers involved in an European military exercise -- we don't know what country they were from -- to demonstrate the power of the attack technique.

Over four weeks, the researchers developed fake pages and closed groups on Facebook that looked like they were associated with the military exercise, as well as profiles impersonating service members both real and imagined.

To recruit soldiers to the pages, they used targeted Facebook advertising. Those pages then promoted the closed groups the researchers had created. Inside the groups, the researchers used their phony accounts to ask the real service members questions about their battalions and their work. They also used these accounts to "friend" service members. According to the report, Facebook's Suggested Friends feature proved helpful in surfacing additional targets.

The researchers also tracked down service members' Instagram and Twitter accounts and searched for other information available online, some of which a bad actor might be able to exploit. "We managed to find quite a lot of data on individual people, which would include sensitive information," Biteniece says. "Like a serviceman having a wife and also being on dating apps."

By the end of the exercise, the researchers identified 150 soldiers, found the locations of several battalions, tracked troop movements, and compelled service members to engage in "undesirable behavior," including leaving their positions against orders.

"Every person has a button. For somebody there's a financial issue, for somebody it's a very appealing date, for somebody it's a family thing," Sarts says. "It's varied, but everybody has a button. The point is, what's openly available online is sufficient to know what that is."

This is the future of warfare. It's one of the reasons China stole all of that data from the Office of Personal Management. If indeed a country's intelligence service was behind the Equifax attack, this is why they did it.

Go back and read this scenario from the Center for Strategic and International Studies. Why wouldn't a country intent on starting a war do it that way?

Posted on February 26, 2019 at 6:10 AM26 Comments

On the Security of Password Managers

There's new research on the security of password managers, specifically 1Password, Dashlane, KeePass, and Lastpass. This work specifically looks at password leakage on the host computer. That is, does the password manager accidentally leave plaintext copies of the password lying around memory?

All password managers we examined sufficiently secured user secrets while in a "not running" state. That is, if a password database were to be extracted from disk and if a strong master password was used, then brute forcing of a password manager would be computationally prohibitive.

Each password manager also attempted to scrub secrets from memory. But residual buffers remained that contained secrets, most likely due to memory leaks, lost memory references, or complex GUI frameworks which do not expose internal memory management mechanisms to sanitize secrets.

This was most evident in 1Password7 where secrets, including the master password and its associated secret key, were present in both a locked and unlocked state. This is in contrast to 1Password4, where at most, a single entry is exposed in a "running unlocked" state and the master password exists in memory in an obfuscated form, but is easily recoverable. If 1Password4 scrubbed the master password memory region upon successful unlocking, it would comply with all proposed security guarantees we outlined earlier.

This paper is not meant to criticize specific password manager implementations; however, it is to establish a reasonable minimum baseline which all password managers should comply with. It is evident that attempts are made to scrub and sensitive memory in all password managers. However, each password manager fails in implementing proper secrets sanitization for various reasons.

For example:

LastPass obfuscates the master password while users are typing in the entry, and when the password manager enters an unlocked state, database entries are only decrypted into memory when there is user interaction. However, ISE reported that these entries persist in memory after the software enters a locked state. It was also possible for the researchers to extract the master password and interacted-with password entries due to a memory leak.

KeePass scrubs the master password from memory and is not recoverable. However, errors in workflows permitted the researchers from extracting credential entries which have been interacted with. In the case of Windows APIs, sometimes, various memory buffers which contain decrypted entries may not be scrubbed correctly.

Whether this is a big deal or not depends on whether you consider your computer to be trusted.

Several people have emailed me to ask why my own Password Safe was not included in the evaluation, and whether it has the same vulnerabilities. My guess about the former is that Password Safe isn't as popular as the others. (This is for two reasons: 1) I don't publicize it very much, and 2) it doesn't have an easy way to synchronize passwords across devices or otherwise store password data in the cloud.) As to the latter: we tried to code Password Safe not to leave plaintext passwords lying around in memory.

So, Independent Security Evaluators: take a look at Password Safe.

Also, remember the vulnerabilities found in many cloud-based password managers back in 2014?

News article. Slashdot thread.

Posted on February 25, 2019 at 6:23 AM51 Comments

Friday Squid Blogging: A Tracking Device for Squid

Really:

After years of "making do" with the available technology for his squid studies, Mooney created a versatile tag that allows him to research squid behavior. With the help of Kakani Katija, an engineer adapting the tag for jellyfish at California's Monterey Bay Aquarium Research Institute (MBARI), Mooney's team is creating a replicable system flexible enough to work across a range of soft-bodied marine animals. As Mooney and Katija refine the tags, they plan to produce an adaptable, open-source package that scientists researching other marine invertebrates can also use.

As usual, you can also use this squid post to talk about the security stories in the news that I haven't covered.

Read my blog posting guidelines here.

Posted on February 22, 2019 at 4:09 PM73 Comments

Gen. Nakasone on US Cyber Command

Really interesting article by and interview with Paul M. Nakasone (Commander of US Cyber Command, Director of the National Security Agency, and Chief of the Central Security Service) in the current issue of Joint Forces Quarterly. He talks about the evolving role of US Cyber Command, and its new posture of "persistent engagement" using a "cyber-persistant force."

From the article:

We must "defend forward" in cyberspace, as we do in the physical domains. Our naval forces do not defend by staying in port, and our airpower does not remain at airfields. They patrol the seas and skies to ensure they are positioned to defend our country before our borders are crossed. The same logic applies in cyberspace. Persistent engagement of our adversaries in cyberspace cannot be successful if our actions are limited to DOD networks. To defend critical military and national interests, our forces must operate against our enemies on their virtual territory as well. Shifting from a response outlook to a persistence force that defends forward moves our cyber capabilities out of their virtual garrisons, adopting a posture that matches the cyberspace operational environment.

From the interview:

As we think about cyberspace, we should agree on a few foundational concepts. First, our nation is in constant contact with its adversaries; we're not waiting for adversaries to come to us. Our adversaries understand this, and they are always working to improve that contact. Second, our security is challenged in cyberspace. We have to actively defend; we have to conduct reconnaissance; we have to understand where our adversary is and his capabilities; and we have to understand their intent. Third, superiority in cyberspace is temporary; we may achieve it for a period of time, but it's ephemeral. That's why we must operate continuously to seize and maintain the initiative in the face of persistent threats. Why do the threats persist in cyberspace? They persist because the barriers to entry are low and the capabilities are rapidly available and can be easily repurposed. Fourth, in this domain, the advantage favors those who have initiative. If we want to have an advantage in cyberspace, we have to actively work to either improve our defenses, create new accesses, or upgrade our capabilities. This is a domain that requires constant action because we're going to get reactions from our adversary.

[...]

Persistent engagement is the concept that states we are in constant contact with our adversaries in cyberspace, and success is determined by how we enable and act. In persistent engagement, we enable other interagency partners. Whether it's the FBI or DHS, we enable them with information or intelligence to share with elements of the CIKR [critical infrastructure and key resources] or with select private-sector companies. The recent midterm elections is an example of how we enabled our partners. As part of the Russia Small Group, USCYBERCOM and the National Security Agency [NSA] enabled the FBI and DHS to prevent interference and influence operations aimed at our political processes. Enabling our partners is two-thirds of persistent engagement. The other third rests with our ability to act -- that is, how we act against our adversaries in cyberspace. Acting includes defending forward. How do we warn, how do we influence our adversaries, how do we position ourselves in case we have to achieve outcomes in the future? Acting is the concept of operating outside our borders, being outside our networks, to ensure that we understand what our adversaries are doing. If we find ourselves defending inside our own networks, we have lost the initiative and the advantage.

[...]

The concept of persistent engagement has to be teamed with "persistent presence" and "persistent innovation." Persistent presence is what the Intelligence Community is able to provide us to better understand and track our adversaries in cyberspace. The other piece is persistent innovation. In the last couple of years, we have learned that capabilities rapidly change; accesses are tenuous; and tools, techniques, and tradecraft must evolve to keep pace with our adversaries. We rely on operational structures that are enabled with the rapid development of capabilities. Let me offer an example regarding the need for rapid change in technologies. Compare the air and cyberspace domains. Weapons like JDAMs [Joint Direct Attack Munitions] are an important armament for air operations. How long are those JDAMs good for? Perhaps 5, 10, or 15 years, some-times longer given the adversary. When we buy a capability or tool for cyberspace...we rarely get a prolonged use we can measure in years. Our capabilities rarely last 6 months, let alone 6 years. This is a big difference in two important domains of future conflict. Thus, we will need formations that have ready access to developers.

Solely from a military perspective, these are obviously the right things to be doing. From a societal perspective -- from the perspective a potential arms race -- I'm much less sure. I'm also worried about the singular focus on nation-state actors in an environment where capabilities diffuse so quickly. But Cyber Command's job is not cybersecurity and resilience.

The whole thing is worth reading, regardless of whether you agree or disagree.

EDITED TO ADD (2/26): As an example, US Cyber Command disrupted a Russian troll farm during the 2018 midterm elections.

Posted on February 22, 2019 at 5:35 AM38 Comments

Reverse Location Search Warrants

The police are increasingly getting search warrants for information about all cell phones in a certain location at a certain time:

Police departments across the country have been knocking at Google's door for at least the last two years with warrants to tap into the company's extensive stores of cellphone location data. Known as "reverse location search warrants," these legal mandates allow law enforcement to sweep up the coordinates and movements of every cellphone in a broad area. The police can then check to see if any of the phones came close to the crime scene. In doing so, however, the police can end up not only fishing for a suspect, but also gathering the location data of potentially hundreds (or thousands) of innocent people. There have only been anecdotal reports of reverse location searches, so it's unclear how widespread the practice is, but privacy advocates worry that Google's data will eventually allow more and more departments to conduct indiscriminate searches.

Of course, it's not just Google who can provide this information.

I am also reminded of a Canadian surveillance program disclosed by Snowden.

I spend a lot of time talking about this sort of thing in Data and Goliath. Once you have everyone under surveillance all the time, many things are possible.

EDITED TO ADD (3/13): Here' the portal law enforcement uses to make its requests.

Posted on February 21, 2019 at 6:33 AM35 Comments

Details on Recent DNS Hijacking

At the end of January, the US Department of Homeland Security issued a warning regarding serious DNS hijacking attempts against US government domains.

Brian Krebs wrote an excellent article detailing the attacks and their implications. Strongly recommended.

Posted on February 20, 2019 at 8:02 AM15 Comments

Estonia's Volunteer Cyber Militia

Interesting -- although short and not very detailed -- article about Estonia's volunteer cyber-defense militia.

Padar's militia of amateur IT workers, economists, lawyers, and other white-hat types are grouped in the city of Tartu, about 65 miles from the Russian border, and in the capital, Tallinn, about twice as far from it. The volunteers, who've inspired a handful of similar operations around the world, are readying themselves to defend against the kind of sustained digital attack that could cause mass service outages at hospitals, banks, and military bases, and with other critical operations, including voting systems. Officially, the team is part of Estonia's 26,000-strong national guard, the Defense League.

[...]

Formally established in 2011, Padar's unit mostly runs on about €150,000 ($172,000) in annual state funding, plus salaries for him and four colleagues. (If that sounds paltry, remember that the country's median annual income is about €12,000.) Some volunteers oversee a website that calls out Russian propaganda posing as news directed at Estonians in Estonian, Russian, English, and German. Other members recently conducted forensic analysis on an attack against a military system, while yet others searched for signs of a broader campaign after discovering vulnerabilities in the country's electronic ID cards, which citizens use to check bank and medical records and to vote. (The team says it didn't find anything, and the security flaws were quickly patched.)

Mostly, the volunteers run weekend drills with troops, doctors, customs and tax agents, air traffic controllers, and water and power officials. "Somehow, this model is based on enthusiasm," says Andrus Ansip, who was prime minister during the 2007 attack and now oversees digital affairs for the European Commission. To gauge officials' responses to realistic attacks, the unit might send out emails with sketchy links or drop infected USB sticks to see if someone takes the bait.

EDITED TO ADD (3/11): Here's a brief interview with the current commander -- and one of the founding members of the unit. Here's a longer presentation.

Posted on February 19, 2019 at 6:36 AM11 Comments

I Am Not Associated with Swift Recovery Ltd.

It seems that someone from a company called Swift Recovery Ltd. is impersonating me -- at least on Telegram. The person is using a photo of me, and is using details of my life available on Wikipedia to convince people that they are me.

They are not.

If anyone has any more information -- stories, screen shots of chats, etc. -- please forward them to me.

Posted on February 18, 2019 at 2:42 PM5 Comments

Friday Squid Blogging: Sharp-Eared Enope Squid

Beautiful photo of a three-inch-long squid.

As usual, you can also use this squid post to talk about the security stories in the news that I haven't covered.

Read my blog posting guidelines here.

Posted on February 15, 2019 at 4:24 PM76 Comments

USB Cable with Embedded Wi-Fi Controller

It's only a prototype, but this USB cable has an embedded Wi-Fi controller. Whoever controls that Wi-Fi connection can remotely execute commands on the attached computer.

Posted on February 14, 2019 at 6:53 AM34 Comments

Cyberinsurance and Acts of War

I had not heard about this case before. Zurich Insurance has refused to pay Mondelez International's claim of $100 million in damages from NotPetya. It claims it is an act of war and therefor not covered. Mondelez is suing.

Those turning to cyber insurance to manage their exposure presently face significant uncertainties about its promise. First, the scope of cyber risks vastly exceeds available coverage, as cyber perils cut across most areas of commercial insurance in an unprecedented manner: direct losses to policyholders and third-party claims (clients, customers, etc.); financial, physical and IP damages; business interruption, and so on. Yet no cyber insurance policies cover this entire spectrum. Second, the scope of cyber-risk coverage under existing policies, whether traditional general liability or property policies or cyber-specific policies, is rarely comprehensive (to cover all possible cyber perils) and often unclear (i.e., it does not explicitly pertain to all manifestations of cyber perils, or it explicitly excludes some).

But it is in the public interest for Zurich and its peers to expand their role in managing cyber risk. In its ideal state, a mature cyber insurance market could go beyond simply absorbing some of the damage of cyberattacks and play a more fundamental role in engineering and managing cyber risk. It would allow analysis of data across industries to understand risk factors and develop common metrics and scalable solutions. It would allow researchers to pinpoint sources of aggregation risk, such as weak spots in widely relied-upon software and hardware platforms and services. Through its financial levers, the insurance industry can turn these insights into action, shaping private-sector behavior and promoting best practices internationally. Such systematic efforts to improve and incentivize cyber-risk management would redress the conditions that made NotPetya possible in the first place. This, in turn, would diminish the onus on governments to retaliate against attacks.

Posted on February 13, 2019 at 6:32 AM27 Comments

Blockchain and Trust

In his 2008 white paper that first proposed bitcoin, the anonymous Satoshi Nakamoto concluded with: "We have proposed a system for electronic transactions without relying on trust." He was referring to blockchain, the system behind bitcoin cryptocurrency. The circumvention of trust is a great promise, but it's just not true. Yes, bitcoin eliminates certain trusted intermediaries that are inherent in other payment systems like credit cards. But you still have to trust bitcoin -- and everything about it.

Much has been written about blockchains and how they displace, reshape, or eliminate trust. But when you analyze both blockchain and trust, you quickly realize that there is much more hype than value. Blockchain solutions are often much worse than what they replace.

First, a caveat. By blockchain, I mean something very specific: the data structures and protocols that make up a public blockchain. These have three essential elements. The first is a distributed (as in multiple copies) but centralized (as in there's only one) ledger, which is a way of recording what happened and in what order. This ledger is public, meaning that anyone can read it, and immutable, meaning that no one can change what happened in the past.

The second element is the consensus algorithm, which is a way to ensure all the copies of the ledger are the same. This is generally called mining; a critical part of the system is that anyone can participate. It is also distributed, meaning that you don't have to trust any particular node in the consensus network. It can also be extremely expensive, both in data storage and in the energy required to maintain it. Bitcoin has the most expensive consensus algorithm the world has ever seen, by far.

Finally, the third element is the currency. This is some sort of digital token that has value and is publicly traded. Currency is a necessary element of a blockchain to align the incentives of everyone involved. Transactions involving these tokens are stored on the ledger.

Private blockchains are completely uninteresting. (By this, I mean systems that use the blockchain data structure but don't have the above three elements.) In general, they have some external limitation on who can interact with the blockchain and its features. These are not anything new; they're distributed append-only data structures with a list of individuals authorized to add to it. Consensus protocols have been studied in distributed systems for more than 60 years. Append-only data structures have been similarly well covered. They're blockchains in name only, and -- as far as I can tell -- the only reason to operate one is to ride on the blockchain hype.

All three elements of a public blockchain fit together as a single network that offers new security properties. The question is: Is it actually good for anything? It's all a matter of trust.

Trust is essential to society. As a species, humans are wired to trust one another. Society can't function without trust, and the fact that we mostly don't even think about it is a measure of how well trust works.

The word "trust" is loaded with many meanings. There's personal and intimate trust. When we say we trust a friend, we mean that we trust their intentions and know that those intentions will inform their actions. There's also the less intimate, less personal trust -- we might not know someone personally, or know their motivations, but we can trust their future actions. Blockchain enables this sort of trust: We don't know any bitcoin miners, for example, but we trust that they will follow the mining protocol and make the whole system work.

Most blockchain enthusiasts have a unnaturally narrow definition of trust. They're fond of catchphrases like "in code we trust," "in math we trust," and "in crypto we trust." This is trust as verification. But verification isn't the same as trust.

In 2012, I wrote a book about trust and security, Liars and Outliers. In it, I listed four very general systems our species uses to incentivize trustworthy behavior. The first two are morals and reputation. The problem is that they scale only to a certain population size. Primitive systems were good enough for small communities, but larger communities required delegation, and more formalism.

The third is institutions. Institutions have rules and laws that induce people to behave according to the group norm, imposing sanctions on those who do not. In a sense, laws formalize reputation. Finally, the fourth is security systems. These are the wide varieties of security technologies we employ: door locks and tall fences, alarm systems and guards, forensics and audit systems, and so on.

These four elements work together to enable trust. Take banking, for example. Financial institutions, merchants, and individuals are all concerned with their reputations, which prevents theft and fraud. The laws and regulations surrounding every aspect of banking keep everyone in line, including backstops that limit risks in the case of fraud. And there are lots of security systems in place, from anti-counterfeiting technologies to internet-security technologies.

In his 2018 book, Blockchain and the New Architecture of Trust, Kevin Werbach outlines four different "trust architectures." The first is peer-to-peer trust. This basically corresponds to my morals and reputational systems: pairs of people who come to trust each other. His second is leviathan trust, which corresponds to institutional trust. You can see this working in our system of contracts, which allows parties that don't trust each other to enter into an agreement because they both trust that a government system will help resolve disputes. His third is intermediary trust. A good example is the credit card system, which allows untrusting buyers and sellers to engage in commerce. His fourth trust architecture is distributed trust. This is emergent trust in the particular security system that is blockchain.

What blockchain does is shift some of the trust in people and institutions to trust in technology. You need to trust the cryptography, the protocols, the software, the computers and the network. And you need to trust them absolutely, because they're often single points of failure.

When that trust turns out to be misplaced, there is no recourse. If your bitcoin exchange gets hacked, you lose all of your money. If your bitcoin wallet gets hacked, you lose all of your money. If you forget your login credentials, you lose all of your money. If there's a bug in the code of your smart contract, you lose all of your money. If someone successfully hacks the blockchain security, you lose all of your money. In many ways, trusting technology is harder than trusting people. Would you rather trust a human legal system or the details of some computer code you don't have the expertise to audit?

Blockchain enthusiasts point to more traditional forms of trust -- bank processing fees, for example -- as expensive. But blockchain trust is also costly; the cost is just hidden. For bitcoin, that's the cost of the additional bitcoin mined, the transaction fees, and the enormous environmental waste.

Blockchain doesn't eliminate the need to trust human institutions. There will always be a big gap that can't be addressed by technology alone. People still need to be in charge, and there is always a need for governance outside the system. This is obvious in the ongoing debate about changing the bitcoin block size, or in fixing the DAO attack against Ethereum. There's always a need to override the rules, and there's always a need for the ability to make permanent rules changes. As long as hard forks are a possibility -- that's when the people in charge of a blockchain step outside the system to change it -- people will need to be in charge.

Any blockchain system will have to coexist with other, more conventional systems. Modern banking, for example, is designed to be reversible. Bitcoin is not. That makes it hard to make the two compatible, and the result is often an insecurity. Steve Wozniak was scammed out of $70K in bitcoin because he forgot this.

Blockchain technology is often centralized. Bitcoin might theoretically be based on distributed trust, but in practice, that's just not true. Just about everyone using bitcoin has to trust one of the few available wallets and use one of the few available exchanges. People have to trust the software and the operating systems and the computers everything is running on. And we've seen attacks against wallets and exchanges. We've seen Trojans and phishing and password guessing. Criminals have even used flaws in the system that people use to repair their cell phones to steal bitcoin.

Moreover, in any distributed trust system, there are backdoor methods for centralization to creep back in. With bitcoin, there are only a few miners of consequence. There's one company that provides most of the mining hardware. There are only a few dominant exchanges. To the extent that most people interact with bitcoin, it is through these centralized systems. This also allows for attacks against blockchain-based systems.

These issues are not bugs in current blockchain applications, they're inherent in how blockchain works. Any evaluation of the security of the system has to take the whole socio-technical system into account. Too many blockchain enthusiasts focus on the technology and ignore the rest.

To the extent that people don't use bitcoin, it's because they don't trust bitcoin. That has nothing to do with the cryptography or the protocols. In fact, a system where you can lose your life savings if you forget your key or download a piece of malware is not particularly trustworthy. No amount of explaining how SHA-256 works to prevent double-spending will fix that.

Similarly, to the extent that people do use blockchains, it is because they trust them. People either own bitcoin or not based on reputation; that's true even for speculators who own bitcoin simply because they think it will make them rich quickly. People choose a wallet for their cryptocurrency, and an exchange for their transactions, based on reputation. We even evaluate and trust the cryptography that underpins blockchains based on the algorithms' reputation.

To see how this can fail, look at the various supply-chain security systems that are using blockchain. A blockchain isn't a necessary feature of any of them. The reasons they're successful is that everyone has a single software platform to enter their data in. Even though the blockchain systems are built on distributed trust, people don't necessarily accept that. For example, some companies don't trust the IBM/Maersk system because it's not their blockchain.

Irrational? Maybe, but that's how trust works. It can't be replaced by algorithms and protocols. It's much more social than that.

Still, the idea that blockchains can somehow eliminate the need for trust persists. Recently, I received an email from a company that implemented secure messaging using blockchain. It said, in part: "Using the blockchain, as we have done, has eliminated the need for Trust." This sentiment suggests the writer misunderstands both what blockchain does and how trust works.

Do you need a public blockchain? The answer is almost certainly no. A blockchain probably doesn't solve the security problems you think it solves. The security problems it solves are probably not the ones you have. (Manipulating audit data is probably not your major security risk.) A false trust in blockchain can itself be a security risk. The inefficiencies, especially in scaling, are probably not worth it. I have looked at many blockchain applications, and all of them could achieve the same security properties without using a blockchain­ -- of course, then they wouldn't have the cool name.

Honestly, cryptocurrencies are useless. They're only used by speculators looking for quick riches, people who don't like government-backed currencies, and criminals who want a black-market way to exchange money.

To answer the question of whether the blockchain is needed, ask yourself: Does the blockchain change the system of trust in any meaningful way, or just shift it around? Does it just try to replace trust with verification? Does it strengthen existing trust relationships, or try to go against them? How can trust be abused in the new system, and is this better or worse than the potential abuses in the old system? And lastly: What would your system look like if you didn't use blockchain at all?

If you ask yourself those questions, it's likely you'll choose solutions that don't use public blockchain. And that'll be a good thing -- especially when the hype dissipates.

This essay previously appeared on Wired.com.

EDITED TO ADD (2/11): Two commentaries on my essay.

I have wanted to write this essay for over a year. The impetus to finally do it came from an invite to speak at the Hyperledger Global Forum in December. This essay is a version of the talk I wrote for that event, made more accessible to a general audience.

It seems to be the season for blockchain takedowns. James Waldo has an excellent essay in Queue. And Nicholas Weaver gave a talk at the Enigma Conference, summarized here. It's a shortened version of this talk.

EDITED TO ADD (2/17): Reddit thread.

EDITED TO ADD (3/1): Two more articles.

Posted on February 12, 2019 at 6:25 AM96 Comments

Friday Squid Blogging: The Hawaiian Bobtail Squid Genome

The Hawaiian Bobtail Squid's genome is half again the size of a human's.

Other facts:

The Hawaiian bobtail squid has two different symbiotic organs, and researchers were able to show that each of these took different paths in their evolution. This particular species of squid has a light organ that harbors a light-producing, or bioluminescent, bacterium that enables the squid to cloak itself from predators. At some point in the past, a major "duplication event" occurred that led to repeat copies of genes that normally exist in the eye. These genes allowed the squid to manipulate the light generated by the bacteria.

As usual, you can also use this squid post to talk about the security stories in the news that I haven't covered.

Read my blog posting guidelines here.

Posted on February 8, 2019 at 4:37 PM152 Comments

Friday Squid Blogging: Multiple Organisms Co-Evolving in a Single Squid

Interesting research on the genomic evolution of the Hawaiian bobtail squid: "These analyses represent the first genomic insights into the evolution of multiple symbiotic organs within a single animal host."

From a news article:

Now, Foster and an international team of researchers have mapped the genome of a Hawaiian bobtail squid, creating a new tool to explore these questions. By parsing the squid's genome, the team has already discovered that the evolution of its light organ followed a completely different pathway than that of a second symbiotic organ, which supports reproduction.

As usual, you can also use this squid post to talk about the security stories in the news that I haven't covered.

Read my blog posting guidelines here.

Posted on February 8, 2019 at 4:32 PM0 Comments

China's AI Strategy and its Security Implications

Gregory C. Allen at the Center for a New American Security has a new report with some interesting analysis and insights into China's AI strategy, commercial, government, and military. There are numerous security -- and national security -- implications.

Posted on February 7, 2019 at 8:15 AM39 Comments

Using Gmail "Dot Addresses" to Commit Fraud

In Gmail addresses, the dots don't matter. The account "bruceschneier@gmail.com" maps to the exact same address as "bruce.schneier@gmail.com" and "b.r.u.c.e.schneier@gmail.com" -- and so on. (Note: I own none of those addresses, if they are actually valid.)

This fact can be used to commit fraud:

Recently, we observed a group of BEC actors make extensive use of Gmail dot accounts to commit a large and diverse amount of fraud. Since early 2018, this group has used this fairly simple tactic to facilitate the following fraudulent activities:

  • Submit 48 credit card applications at four US-based financial institutions, resulting in the approval of at least $65,000 in fraudulent credit
  • Register for 14 trial accounts with a commercial sales leads service to collect targeting data for BEC attacks
  • File 13 fraudulent tax returns with an online tax filing service
  • Submit 12 change of address requests with the US Postal Service
  • Submit 11 fraudulent Social Security benefit applications
  • Apply for unemployment benefits under nine identities in a large US state
  • Submit applications for FEMA disaster assistance under three identities

In each case, the scammers created multiple accounts on each website within a short period of time, modifying the placement of periods in the email address for each account. Each of these accounts is associated with a different stolen identity, but all email from these services are received by the same Gmail account. Thus, the group is able to centralize and organize their fraudulent activity around a small set of email accounts, thereby increasing productivity and making it easier to continue their fraudulent behavior.

This isn't a new trick. It has been previously documented as a way to trick Netflix users.

News article.

Slashdot thread.

Posted on February 6, 2019 at 10:24 AM34 Comments

Major Zcash Vulnerability Fixed

Zcash just fixed a vulnerability that would have allowed "infinite counterfeit" Zcash.

Like all the other blockchain vulnerabilities and updates, this demonstrates the ridiculousness of the notion that code can replace people, that trust can be encompassed in the protocols, or that human governance is not ncessary.

Posted on February 5, 2019 at 2:59 PM46 Comments

Facebook's New Privacy Hires

The Wired headline sums it up nicely -- "Facebook Hires Up Three of Its Biggest Privacy Critics":

In December, Facebook hired Nathan White away from the digital rights nonprofit Access Now, and put him in the role of privacy policy manager. On Tuesday of this week, lawyers Nate Cardozo, of the privacy watchdog Electronic Frontier Foundation, and Robyn Greene, of New America's Open Technology Institute, announced they also are going in-house at Facebook. Cardozo will be the privacy policy manager of WhatsApp, while Greene will be Facebook's new privacy policy manager for law enforcement and data protection.

I know these people. They're ethical, and they're on the right side. I hope they continue to do their good work from inside Facebook.

Posted on February 4, 2019 at 11:07 AM31 Comments

Friday Squid Blogging: Squid with Chorizo, Tomato, and Beans

Nice recipe.

As usual, you can also use this squid post to talk about the security stories in the news that I haven't covered.

Read my blog posting guidelines here.

Posted on February 1, 2019 at 4:38 PM57 Comments

Public-Interest Tech at the RSA Conference

Our work in cybersecurity is inexorably intertwined with public policy and­ -- more generally­ -- the public interest. It's obvious in the debates on encryption and vulnerability disclosure, but it's also part of the policy discussions about the Internet of Things, cryptocurrencies, artificial intelligence, social media platforms, and pretty much everything else related to IT.

This societal dimension to our traditionally technical area is bringing with it a need for public-interest technologists.

Defining this term is difficult. One blog post described public-interest technologists as "technology practitioners who focus on social justice, the common good, and/or the public interest." A group of academics in this field wrote that "public-interest technology refers to the study and application of technology expertise to advance the public interest/generate public benefits/promote the public good."

I think of public-interest technologists as people who combine their technological expertise with a public-interest focus, either by working on tech policy (for the EFF or as a congressional staffer, as examples), working on a technology project with a public benefit (such as Tor or Signal), or working as a more traditional technologist for an organization with a public-interest focus (providing IT security for Human Rights Watch, as an example). Public-interest technology isn't one thing; it's many things. And not everyone likes the term. Maybe it's not the most accurate term for what different people do, but it's the best umbrella term that covers everyone.

It's a growing field -- one far broader than cybersecurity -- and one that I am increasingly focusing my time on. I maintain a resources page for public-interest technology. (This is the single best document to read about the current state of public-interest technology, and what is still to be done.)

This year, I am bringing some of these ideas to the RSA Conference. In partnership with the Ford Foundation, I am hosting a mini-track on public-interest technology. Six sessions throughout the day on Thursday will highlight different aspects of this important work. We'll look at public-interest technologists inside governments, as part of civil society, at universities, and in corporate environments.

  1. How Public-Interest Technologists are Changing the World . This introductory panel lays the groundwork for the day to come. I'll be joined on stage with Matt Mitchell of Tactical Tech, and we'll discuss how public-interest technologists are already changing the world.
  2. Public-Interest Tech in Silicon Valley. Most of us work for technology companies, and this panel discusses public-interest technology work within companies. Mitchell Baker of Mozilla Corp. and Cindy Cohn of the EFF will lead the discussion, looking at both public-interest projects within corporations and employee activism initiatives by corporate employees.
  3. Working in Civil Society. Bringing a technological perspective into civil society can transform how organizations do their work. Through a series of lightning talks, this session examines how this transformation can happen from a variety of perspectives: exposing government surveillance, protecting journalists worldwide, preserving a free and open Internet, bringing a security focus to artificial intelligence research, protecting NGO networks, and more. For those of us in security, bringing tech tools to those who need them is core to what we do.
  4. Government Needs You. Government needs technologists at all levels. We're needed on legislative staffs and at regulatory agencies in order to make effective tech policy, but we're also needed elsewhere to implement policy more broadly. We're needed to advise courts, testify at hearings, and serve on advisory committees. At this session, you'll hear from public-interest technologists who have had a major impact on government from a variety of positions, and learn about ways you can get involved.
  5. Changing Academia. Higher education needs to incorporate a public-interest perspective in technology departments, and a technology perspective in public-policy departments. This could look like ethics courses for computer science majors, programming for law students, or joint degrees that combine technology and social science. Danny Weitzner of MIT and Latanya Sweeney of Harvard will discuss efforts to build these sorts of interdisciplinary classes, programs, and institutes.
  6. The Future of Public-Interest Tech Creating an environment where public-interest technology can flourish will require a robust pipeline: more people wanting to go into this field, more places for them to go, and an improved market that matches supply with demand. In this closing session, Jenny Toomey of the Ford Foundation and I will sum up the day and discuss future directions for growing the field, funding trajectories, highlighting outstanding needs and gaps, and describing how you can get involved.

Check here for times and locations, and be sure to reserve your seat.

We all need to help. I don't mean that we all need to quit our jobs and go work on legislative staffs; there's a lot we can do while still maintaining our existing careers. We can advise governments and other public-interest organizations. We can agitate for the public interest inside the corporations we work for. We can speak at conferences and write opinion pieces for publication. We can teach part-time at all levels. But some of us will need to do this full-time.

There's an interesting parallel to public-interest law, which covers everything from human-rights lawyers to public defenders. In the 1960s, that field didn't exist. The field was deliberately created, funded by organizations like the Ford Foundation. They created a world where public-interest law is valued. Today, when the ACLU advertises for a staff attorney, paying a third to a tenth of a normal salary, it gets hundreds of applicants. Today, 20% of Harvard Law School grads go into public-interest law, while the percentage of computer science grads doing public-interest work is basically zero. This is what we need to fix.

Please stop in at my mini-track. Come for a panel that interests you, or stay for the whole day. Bring your ideas. Find me to talk about this further. Pretty much all the major policy debates of this century will have a strong technological component -- and an important cybersecurity angle -- and we all need to get involved.

This essay originally appeared on the RSA Conference blog.

Michael Brennan of the Ford Foundation also wrote an essay on the event.

Posted on February 1, 2019 at 9:48 AM22 Comments

Sidebar photo of Bruce Schneier by Joe MacInnis.