SSL and internet security news

aes

Auto Added by WPeMatico

Self-Propagating Smart Light Bulb Worm

This is exactly the sort of Internet-of-Things attack that has me worried:

“IoT Goes Nuclear: Creating a ZigBee Chain Reaction” by Eyal Ronen, Colin OFlynn, Adi Shamir and Achi-Or Weingarten.

Abstract: Within the next few years, billions of IoT devices will densely populate our cities. In this paper we describe a new type of threat in which adjacent IoT devices will infect each other with a worm that will spread explosively over large areas in a kind of nuclear chain reaction, provided that the density of compatible IoT devices exceeds a certain critical mass. In particular, we developed and verified such an infection using the popular Philips Hue smart lamps as a platform. The worm spreads by jumping directly from one lamp to its neighbors, using only their built-in ZigBee wireless connectivity and their physical proximity. The attack can start by plugging in a single infected bulb anywhere in the city, and then catastrophically spread everywhere within minutes, enabling the attacker to turn all the city lights on or off, permanently brick them, or exploit them in a massive DDOS attack. To demonstrate the risks involved, we use results from percolation theory to estimate the critical mass of installed devices for a typical city such as Paris whose area is about 105 square kilometers: The chain reaction will fizzle if there are fewer than about 15,000 randomly located smart lights in the whole city, but will spread everywhere when the number exceeds this critical mass (which had almost certainly been surpassed already).

To make such an attack possible, we had to find a way to remotely yank already installed lamps from their current networks, and to perform over-the-air firmware updates. We overcame the first problem by discovering and exploiting a major bug in the implementation of the Touchlink part of the ZigBee Light Link protocol, which is supposed to stop such attempts with a proximity test. To solve the second problem, we developed a new version of a side channel attack to extract the global AES-CCM key that Philips uses to encrypt and authenticate new firmware. We used only readily available equipment costing a few hundred dollars, and managed to find this key without seeing any actual updates. This demonstrates once again how difficult it is to get security right even for a large company that uses standard cryptographic techniques to protect a major product.

EDITED TO ADD: BoingBoing post. Slashdot thread.

Powered by WPeMatico

IRS Encourages Poor Cryptography

I’m not sure what to make of this, or even what it means. The IRS has a standard called IDES: International Data Exchange Service: “The International Data Exchange Service (IDES) is an electronic delivery point where Financial Institutions (FI) and Host Country Tax Authorities (HCTA) can transmit and exchange FATCA data with the United States.” It’s like IRS data submission, but for other governments and foreign banks.

Buried in one of the documents are the rules for encryption:

While performing AES encryption, there are several settings and options depending on the tool used to perform encryption. IRS recommended settings should be used to maintain compatibility:

  • Cipher Mode: ECB (Electronic Code Book).
  • Salt: No salt value
  • Initialization Vector: No Initialization Vector (IV). If an IV is present, set to all zeros to avoid affecting the encryption.
  • Key Size: 256 bits / 32 bytes ­ Key size should be verified and moving the key across operating systems can affect the key size.
  • Encoding: There can be no special encoding. The file will contain only the raw encrypted bytes.
  • Padding: PKCS#7 or PKCS#5.

ECB? Are they serious?

Powered by WPeMatico