Entries Tagged "AES"

Page 1 of 4

Hyundai Uses Example Keys for Encryption System

This is a dumb crypto mistake I had not previously encountered:

A developer says it was possible to run their own software on the car infotainment hardware after discovering the vehicle’s manufacturer had secured its system using keys that were not only publicly known but had been lifted from programming examples.

[…]

“Turns out the [AES] encryption key in that script is the first AES 128-bit CBC example key listed in the NIST document SP800-38A [PDF]”.

[…]

Luck held out, in a way. “Greenluigi1” found within the firmware image the RSA public key used by the updater, and searched online for a portion of that key. The search results pointed to a common public key that shows up in online tutorials like “RSA Encryption & Decryption Example with OpenSSL in C.“

EDITED TO ADD (8/23): Slashdot post.

Posted on August 22, 2022 at 6:38 AM • View Comments

Brexit Deal Mandates Old Insecure Crypto Algorithms

In what is surely an unthinking cut-and-paste issue, page 921 of the Brexit deal mandates the use of SHA-1 and 1024-bit RSA:

The open standard s/MIME as extension to de facto e-mail standard SMTP will be deployed to encrypt messages containing DNA profile information. The protocol s/MIME (V3) allows signed receipts, security labels, and secure mailing lists… The underlying certificate used by s/MIME mechanism has to be in compliance with X.509 standard…. The processing rules for s/MIME encryption operations… are as follows:

  1. the sequence of the operations is: first encryption and then signing,
  2. the encryption algorithm AES (Advanced Encryption Standard) with 256 bit key length and RSA with 1,024 bit key length shall be applied for symmetric and asymmetric encryption respectively,
  3. the hash algorithm SHA-1 shall be applied.
  4. s/MIME functionality is built into the vast majority of modern e-mail software packages including Outlook, Mozilla Mail as well as Netscape Communicator 4.x and inter-operates among all major e-mail software packages.

And s/MIME? Bleah.

Posted on December 31, 2020 at 6:19 AM • View Comments

Securing Internet Videoconferencing Apps: Zoom and Others

The NSA just published a survey of video conferencing apps. So did Mozilla.

Zoom is on the good list, with some caveats. The company has done a lot of work addressing previous security concerns. It still has a bit to go on end-to-end encryption. Matthew Green looked at this. Zoom does offer end-to-end encryption if 1) everyone is using a Zoom app, and not logging in to the meeting using a webpage, and 2) the meeting is not being recorded in the cloud. That’s pretty good, but the real worry is where the encryption keys are generated and stored. According to Citizen Lab, the company generates them.

The Zoom transport protocol adds Zoom’s own encryption scheme to RTP in an unusual way. By default, all participants’ audio and video in a Zoom meeting appears to be encrypted and decrypted with a single AES-128 key shared amongst the participants. The AES key appears to be generated and distributed to the meeting’s participants by Zoom servers. Zoom’s encryption and decryption use AES in ECB mode, which is well-understood to be a bad idea, because this mode of encryption preserves patterns in the input.

The algorithm part was just fixed:

AES 256-bit GCM encryption: Zoom is upgrading to the AES 256-bit GCM encryption standard, which offers increased protection of your meeting data in transit and resistance against tampering. This provides confidentiality and integrity assurances on your Zoom Meeting, Zoom Video Webinar, and Zoom Phone data. Zoom 5.0, which is slated for release within the week, supports GCM encryption, and this standard will take effect once all accounts are enabled with GCM. System-wide account enablement will take place on May 30.

There is nothing in Zoom’s latest announcement about key management. So: while the company has done a really good job improving the security and privacy of their platform, there seems to be just one step remaining to fully encrypt the sessions.

The other thing I want Zoom to do is to make the security options necessary to prevent Zoombombing to be made available to users of the free version of that platform. Forcing users to pay for security isn’t a viable option right now.

Finally—I use Zoom all the time. I finished my Harvard class using Zoom; it’s the university standard. I am having Inrupt company meetings on Zoom. I am having professional and personal conferences on Zoom. It’s what everyone has, and the features are really good.

Posted on April 30, 2020 at 10:24 AM • View Comments

Calculating the Benefits of the Advanced Encryption Standard

NIST has completed a study—it was published last year, but I just saw it recently—calculating the costs and benefits of the Advanced Encryption Standard.

From the conclusion:

The result of performing that operation on the series of cumulated benefits extrapolated for the 169 survey respondents finds that present value of benefits from today’s perspective is approximately $8.9 billion. On the other hand, the present value of NIST’s costs from today’s perspective is $127 million. Thus, the NPV from today’s perspective is $8,772,000,000; the B/C ratio is therefore 70.2/1; and a measure (explained in detail in Section 6.1) of the IRR for the alternative investment perspective is 31%; all are indicators of a substantial economic impact.

Extending the approach of looking back from 2017 to the larger national economy required the selection of economic sectors best represented by the 169 survey respondents. The economic sectors represented by ten or more survey respondents include the following: agriculture; construction; manufacturing; retail trade; transportation and warehousing; information; real estate rental and leasing; professional, scientific, and technical services; management services; waste management; educational services; and arts and entertainment. Looking at the present value of benefits and costs from 2017’s perspective for these economic sectors finds that the present value of benefits rises to approximately $251 billion while the present value of NIST’s costs from today’s perspective remains the same at $127 million. Therefore, the NPV of the benefits of the AES program to the national economy from today’s perspective is $250,473,200,000; the B/C ratio is roughly 1976/1; and the appropriate, alternative (explained in Section 6.1) IRR and investing proceeds at the social rate of return is 53.6%.

The report contains lots of facts and figures relevant to crypto policy debates, including the chaotic nature of crypto markets in the mid-1990s, the number of approved devices and libraries of various kinds since then, other standards that invoke AES, and so on.

There’s a lot to argue with about the methodology and the assumptions. I don’t know if I buy that the benefits of AES to the economy are in the billions of dollars, mostly because we in the cryptographic community would have come up with alternative algorithms to triple-DES that would have been accepted and used. Still, I like seeing this kind of analysis about security infrastructure. Security is an enabling technology; it doesn’t do anything by itself, but instead allows all sorts of things to be done. And I certainly agree that the benefits of a standardized encryption algorithm that we all trust and use outweigh the cost by orders of magnitude.

And this isn’t the first time NIST has conducted economic impact studies. It released a study of the economic impact of DES in 2001.

Posted on October 22, 2019 at 5:56 AM • View Comments

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.

Posted on November 9, 2016 at 6:54 AM • View Comments

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?

Posted on February 18, 2015 at 6:42 AM • View Comments

1 2 3 4

Sidebar photo of Bruce Schneier by Joe MacInnis.