Edge processing architectures in today’s autonomous and AI military systems, process an ever growing amount of sensor data. Many of these systems or devices used for edge processing applications in forward-deployed environments need to be small, rugged and agile. To handle this extreme workload, system architects must design boards using the fastest field-programmable gate array (FPGA) devices and multicore processors. These devices cannot provide peak performance without massive amounts of high-speed DDR4 memory for resident data and real-time execution. Faced with additional challenges, the system architect must design these systems to meet the size, weight and power (SWaP) constraints of smaller, more agile edge processing platforms integral to our warfighters’ mission success. To support the system requirements, each embedded board within the system could need a minimum of 64GB of memory per processor, equating to more than 128 separate commercial-grade memory devices or multiple dual inline memory modules (DIMM), for layout on a printed circuit board. This is not a feasible solution for the embedded boards at the core of ultra-compact edge processing architectures in military systems operating in harsh, forward-deployed environments. Instead, high-density, military-grade memory manufactured with state-of-the-art 3D packaging technology must be utilized for space and power savings, while maintaining reliability in harsh environments.Read More
In military environments, seconds can be the difference between life or death and mission success or failure. A soldier in hostile territory needs their mobile system to rapidly process sensor data to accurately analyze threats and take action. Intelligent sensor systems using artificial intelligence (AI) to make automatic critical decisions without human intervention rely on sophisticated algorithms to process sensor data real-time at the point of generation to ensure a rapid and accurate decision can be made. This real-time processing of data at the point of generation and consumption, decentralized from a data center or the cloud, is Edge Processing. Each local system or device at the “edge” is self-sufficient to collect, process, store and disseminate data into action enabling the intelligent sensor and effector mission systems our military needs to carry out daily operations. These systems that enable mobile computing and artificial intelligence could be part of an unmanned aerial vehicle (UAV),unmanned ground vehicle (UGV) or a base camp collecting surveillance data of its surroundings to warn of incoming threats.
In my prior three posts, I provided an overview of encryption key fundamentals and the various encryption key mode strategies that can be implemented in a Mercury secure SSD. If you did not read those, stop everything and go back to them now! Or, stay here, keep reading and you’ll find a simple, easy-to-use process flow diagram to guide you to the best key management mode for your application.
It is important to note, these are only general guidelines. If you have questions or doubts, consult with a security implementation expert. In this entry, I will also share our new key management mode for secure boot which is under development and releasing soon.
The first question to ask when getting started: will the data be stored on an end user device for a CSfC-approved implementation? If so, the key management mode options are limited to either Mode 1 or Mode 6. If the program is a black key program, Mode 6 is required.
If your data storage implementation is not intended for the CSfC program, answering these questions below will help in your decision:
- Is data recovery after key purge required? The answer to this question determines whether you need a self-generated key (Mode 1) or a user-generated key (Modes 2 through 6).
- Is the program a black key program? If so, Modes 5 and 6 are appropriate. Mode 6 includes an ATA password authentication, which is recommended unless there is a specific justification to avoid doing so.
- If not a black key program, is automatic key purge beneficial or required for the mission? Session keys provide automatic key purge when power is removed from the device.
- Is the added security layer of an ATA password required for the specific security implementation? If unsure of the answer to this question, it is best to err on the side of caution and implement an ATA password.
In the first two posts of this series, I reviewed fundamental terms and concepts of encryption key classifications and discussed roles of passwords versus keys and hash algorithms. In this post, I will provide detail on each key management mode available on a Mercury secure SSD, not all of which may be supported by other SSD manufacturers.
Encryption Key Modes
While the complexity of implementation increases from one mode to the next in the following discussion, end user responsibility also increases. It is imperative to ensure that end users have the proper knowledge, training and infrastructure to successfully create, store, protect and distribute encryption keys and passwords. With these capabilities, the flexibility and security benefits of the more complex modes can be fully realized. Read More
In my first post of this series, I explained terms relating to encryption keys and the standards that exist governing encryption key algorithms. Now I will spend some time on ATA passwords and how they correlate to encryption keys.
Clarifying the Functions of an Encryption Key and ATA Password
The role of an encryption key is commonly confused with the role of an ATA password.
The only purpose of an encryption key is to convert data to cipher text so it is illegible to anyone accessing the data without proper authorization and to then decrypt data back to plain text.
Imagine a US operative on a covert mission is comprised in enemy territory. His laptop, now in the hands of the enemy, contains highly sensitive data stored on the factory-installed SSD and protected only by his 12-character Windows password. A skilled adversary using a brute force attack will quickly gain access to this data. Would you feel safe having our national interests stored on the same type of drive as your laptop? Without the use of a secure storage device with properly implemented encryption and encryption keys, data could easily fall into the enemy’s hands.
Defense News recently released their annual Outlook . If you haven’t seen it yet, I highly recommend it. It’s a great read consisting of a few dozen essays by world leaders looking at the trends and issues, like multi-domain operations, that will most impact the global defense industry.
This year, one essay in particular jumped out at me. General David Goldfein, Chief of Staff of the US Air Force, wrote an insightful article about multi-domain operations. His analogy of lanterns from the Revolutionary War is very apt, and it helps put into perspective the challenges we face today. Perhaps this quote from his essay is most concise:
“Whoever figures out how to quickly gather information in various domains and
just as quickly direct military actions will have the decisive advantage in battle.”
When General Goldfein talks about multi-domain, he is referring to the military’s work on land, at sea, in the air, in space and in the electromagnetic and cyberspace realms. Traditionally, most defense forces have focused on one domain at a time – in silos. Hence, why we have the Army (for land), Navy (for sea) and Air Force (for air). But domains are not mutually exclusive. They need to work interactively in order to gain the most benefit. As was quickly discovered as early as WWI, air supremacy can significantly improve land operations.
At a high level, the vast majority of contemporary compute processing hardware may be divided into two domains: powerful data center processors and smaller, embedded devices. Embedded devices have the support of their data center big brothers via a network connection, giving them access to big data applications.
This approach works for many applications, but not all. Remotely accessed military tactical clouds require data center-like capabilities without data center support. This is achieved by embedding data center processors into military platforms using open system architectures (OSAs) and is ushering in next-generation military mission capabilities.
In the first post of this series, we discussed the history of electronic warfare as it was being developed during WWII. While much has changed in the last 80 years, one constant remains true—the cat-and-mouse game to develop the superior technology that grants the owner control over the electromagnetic spectrum (EMS). When one nation deploys a new radar system, its adversary begins work on the technology to jam the radar. This prompts the first nation to modify their radar system with new features to protect it from the jammer, which brings us to the final topic in this series—electronic protection.
Who remembers that scene in the movie Spaceballs where Lone Starr jams the enemy radar using raspberry jam, causing it to lose the “bleeps, the sweeps, and the creeps”? While Mel Brooks does show what electronic warfare can do, the details aren’t exactly accurate. In this post, we will clear up some of these details in our discussion on electronic attack.