In this post, we continue our series on RF4CE by discussing the mechanisms the protocol uses for security. We encourage you to read the first post for background on the purpose of this post and discussion of security levels and keying techniques. This post will explain how RF4CE devices pair and how payloads are encrypted and protected. Additionally, we’ll explain some of the problems with RF4CE security, and discuss potential remediations.
My team talks a lot about “proactive security” – the concept of baking cybersecurity measures into architecture and design as opposed to responding to vulnerabilities and breaches when they occur. However, I lacked a quantitative answer when recently asked: “how do you convince businesses to start being proactive?”
In the course of security assessments we often come across protocols and communication methods that are not widely known outside of specific industry use. This article is the first in a series of deep dives on one such protocol, RF4CE. In this article, we talk about the background of RF4CE and its use cases, as well as providing an introduction to the basics of RF4CE.
This year at INFILTRATE 2019, I got together with fellow RPISEC alumnus and Boston Cybernetics Institute co-founder Jeremy Blackthorne to present “Three Heads Are Better Than One: Mastering NSA’s Ghidra Reverse Engineering Tool”. Around 50 minutes into that presentation, I presented a demo of a proof of concept script I built to trace out how inputs to malloc are derived. In this blog post, we’ll take a deeper look at that script.
Windows developers may be familiar with “banned.h” or “strsafe” libraries. Introducing safe libraries to development is nothing new, as was covered in the 2007 presentation on SDL for Windows Vista (slide 7). While basic, these basic libraries have been shown to provide significant value - as discussed later in the deck, 41% of bugs that Microsoft removed in Vista early on were due to removal of ‘banned’ API function calls.
This is the first of a multi-part series where we will share some of our methodology for supply chain verification in situations where there is very limited information. This content was previously shared by Sophia d’Antoine at Square’s r00ted1 Conference on November 14th, 2018 in NYC. We have previously shared our thoughts on the importance of supply chain validation with regard to hardware attacks, but this blog series will delve deeper into the specifics related to case alleged in Bloomberg Businessweek’s “The Big Hack” article.
In the past few months, media reporting1 2 on alleged Chinese backdoors via one or more types of hardware implants which compromised American products and companies has raised the public’s awareness of the risk of security compromise via hardware. For those of us who deal with hardware security daily, such allegations are not a big surprise. Our team has worked on designing, securing, and hacking hardware used in places ranging from startups to security-critical government applications, and one item that is in almost every assessment that we do is a circuit board tear-down and detailed parts identification.
In the hardware hacking community, one of the tried-and-true “go to” tools for serial communication, dumping SPI flash chips, and interacting with basic JTAG interfaces is the GoodFET, developed by our neighbor Travis Goodspeed. Some of the GoodFET instructions are a bit outdated and fragmented, and we recently were asked for help installing this on a modern Debian-based system, namely the Kali Linux security distribution. We have written up those procedures here in the hope that they are useful to people working with the GoodFET hardware.
While we are always excited to both learn and share the latest technical developments in cybersecurity (the recent Black Hat and DEF CON conferences were no exception), we also enjoy stepping back once in a while to look at macro trends in the embedded security industry. While security is a top priority in many enterprise and industrial settings, here are three key concepts that we think are important for us all to keep in mind:
SummerCon is a different type of conference than most, and honestly sometimes it’s tough to hear the talks over the noise of the crowd at the bar. This year, the organizers added a second venue to try to spread out the noise from the great conversations and impromptu meetings, so some of the talks could be heard. We wanted to share a few notes on our teams’ key takeaways from the weekend.
Copyright © 2012-2019, River Loop Security LLC. All Rights Reserved.
Template ported by DevCows
