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.
A few months ago, Mercury partnered with the Society of Women Engineers to host our first Women in Technology Night at our headquarters in Andover. I was fortunate enough to have panelists Star Dargin, CEO of Star Leadership and Susan Macchia, Senior Manager at Endeavor Robotics join me in giving insight on our career progression, experiences, and steps taken to earn leadership roles. I was thrilled to see a room full of participants networking and hearing our stories, as well as an engaged audience on our livestream and Facebook Live.
I walked away from this event thinking more about two important topics: women in STEM (Science, Technology, Engineering, and Math) and work-life integration.
From the interview process to now working at Mercury, I’ve found that the company holds true to its high ratings on Glassdoor.
I interviewed in person at the San Jose office for my first post-graduation role. There were many aspects I enjoyed about the interview, but the honesty, energy, and thoughtfulness in the questions asked really made the company stand out from others. I could feel the interviewers’ enthusiasm as they spoke about Mercury and their roles, and it became clear to me that they were truly committed.
During my interview, I was asked about the worst and best managers I have encountered at my previous jobs. This question opened up the door to reflect on the different types of management styles that have worked (or not worked) for me in the past. Unique questions similar to this one challenged me to better understand how I work.
At the end of my interview, it was my turn to ask questions. During our discussion, the hiring manager was completely transparent, honest, and professional. I was sold, as I strongly value these traits in a manager. Read More
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.