Entries Tagged "hardware"

Page 13 of 18

Hard-Drive Steganography through Fragmentation

Clever:

Khan and his colleagues have written software that ensures clusters of a file, rather than being positioned at the whim of the disc drive controller chip, as is usually the case, are positioned according to a code. All the person at the other end needs to know is which file’s cluster positions have been encoded.

The code depends on whether sequential clusters in a file are situated adjacent to each other on the hard disc or not. If they are adjacent, this corresponds to a binary 1 in the secret message.

Paper.

Posted on April 25, 2011 at 5:24 AM • View Comments

Erasing Data from Flash Drives

“Reliably Erasing Data From Flash-Based Solid State Drives,” by Michael Wei, Laura M. Grupp, Frederick E. Spada, and Steven Swanson.

Abstract: Reliably erasing data from storage media (sanitizing the media) is a critical component of secure data management. While sanitizing entire disks and individual files is well-understood for hard drives, flash-based solid state disks have a very different internal architecture, so it is unclear whether hard drive techniques will work for SSDs as well.

We empirically evaluate the effectiveness of hard drive-oriented techniques and of the SSDs’ built-in sanitization commands by extracting raw data from the SSD’s flash chips after applying these techniques and commands. Our results lead to three conclusions: First, built-in commands are effective, but manufacturers sometimes implement them incorrectly. Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive. Third, none of the existing hard drive-oriented techniques for individual file sanitization are effective on SSDs.

This third conclusion leads us to develop flash translation layer extensions that exploit the details of flash memory’s behavior to efficiently support file sanitization. Overall, we find that reliable SSD sanitization requires built-in, verifiable sanitize operations.

News article. Video of talk.

Posted on March 1, 2011 at 6:29 AM • View Comments

PlugBot

Interesting:

PlugBot is a hardware bot. It’s a covert penetration testing device designed for use during physical penetration tests. PlugBot is a tiny computer that looks like a power adapter; this small size allows it to go physically undetected all the while powerful enough to scan, collect and deliver test results externally.

How do you use it?

Gain access to the target location (conference room?), plug the PlugBot in the nearest wall outlet and walk out. The PlugBot is configured to make an external connection (Wi-fi or Ethernet) to a specified IP address to receive instructions. Central Command allows the penetration tester to invoke scripts and applications. Output as a result of testing is encrypted and securely transmitted to the Drop Zone where data is imported into Central Command for analysis by the pen tester.

Note that it has a squid logo.

Posted on December 24, 2010 at 1:14 PM • View Comments

Wanted: Skein Hardware Help

As part of NIST’s SHA-3 selection process, people have been implementing the candidate hash functions on a variety of hardware and software platforms. Our team has implemented Skein in Intel’s 32 nm ASIC process, and got some impressive performance results (presentation and paper). Several other groups have implemented Skein in FPGA and ASIC, and have seen significantly poorer performance. We need help understanding why.

For example, a group led by Brian Baldwin at the Claude Shannon Institute for Discrete Mathematics, Coding and Cryptography implemented all the second-round candidates in FPGA (presentation and paper). Skein performance was terrible, but when they checked their code, they found an error. Their corrected performance comparison (presentation and paper) has Skein performing much better and in the top ten.

We suspect that the adders in all the designs may not be properly optimized, although there may be other performance issues. If we can at least identify (or possibly even fix) the slowdowns in the design, it would be very helpful, both for our understanding and for Skein’s hardware profile. Even if we find that the designs are properly optimized, that would also be good to know.

A group at George Mason University led by Kris Gaj implemented all the second-round candidates in FPGA (presentation, paper, and much longer paper). Skein had the worst performance of any of the implementations. We’re looking for someone who can help us understand the design, and determine if it can be improved.

Another group, led by Stefan Tillich at University of Bristol, implemented all the candidates in 180 nm custom ASIC (presentation and paper). Here, Skein is one of the worst performers. We’re looking for someone who can help us understand what this group did.

Three other groups—one led by Patrick Schaumont of Virginia Tech (presentation and paper), another led by Shin’ichiro Matsuo at National Institute of Information and Communications Technology in Japan (presentation and paper), and a third led by Luca Henzen at ETH Zurich (paper with appendix, and conference version)—implemented the SHA-3 candidates. Again, we need help understanding how their Skein performance numbers are so different from ours.

We’re looking for people with FPGA and ASIC skills to work with the Skein team. We don’t have money to pay anyone; co-authorship on a paper (and a Skein polo shirt) is our primary reward. Please send me e-mail if you’re interested.

Posted on September 1, 2010 at 1:17 PM • View Comments

Security for Implantable Medical Devices

Interesting study: “Patients, Pacemakers, and Implantable Defibrillators: Human Values and Security for Wireless Implantable Medical Devices,” Tamara Denning, Alan Borning, Batya Friedman, Brian T. Gill, Tadayoshi Kohno, and William H. Maisel.

Abstract: Implantable medical devices (IMDs) improve patients’ quality of life and help sustain their lives. In this study, we explore patient views and values regarding their devices to inform the design of computer security for wireless IMDs. We interviewed 13 individuals with implanted cardiac devices. Key questions concerned the evaluation of 8 mockups of IMD security systems. Our results suggest that some systems that are technically viable are nonetheless undesirable to patients. Patients called out a number of values that affected their attitudes towards the systems, including perceived security, safety, freedom from unwanted cultural and historical associations, and self-image. In our analysis, we extend the Value Sensitive Design value dams and flows technique in order to suggest multiple, complementary systems; in our discussion, we highlight some of the usability, regulatory, and economic complexities that arise from offering multiple options. We conclude by offering design guidelines for future security systems for IMDs.

Posted on April 15, 2010 at 1:55 PM • View Comments

Storing Cryptographic Keys with Invisible Tattoos

This idea, by Stuart Schechter at Microsoft Research, is—I think—clever:

Abstract: Implantable medical devices, such as implantable cardiac defibrillators and pacemakers, now use wireless communication protocols vulnerable to attacks that can physically harm patients. Security measures that impede emergency access by physicians could be equally devastating. We propose that access keys be written into patients’ skin using ultraviolet-ink micropigmentation (invisible tattoos).

It certainly is a new way to look at the security threat model.

Posted on April 15, 2010 at 6:43 AM • View Comments

1 … 11 12 13 14 15 … 18

Sidebar photo of Bruce Schneier by Joe MacInnis.