Manufacturing and provisioning

Hi, I'm Matthew Clark. And this is Module 6: Secure Build, Ship, and Operate. Congratulations. We've completed Module 5. This slide shows our progress towards our certificate of completion. Let's begin our new module with Lesson 6.1: Manufacturing and Provisioning. In this lesson, we'll look at insecure manufacturing. We'll discuss common provisioning mistakes and also how to address those using the IoTSF framework. So let's get started. We've discussed the manufacturing process all throughout this course. And as a review, let's discuss some of the threats and impacts to that process. Well, let's start with counterfeiting. And this can include knockoff devices made of cheap materials and containing flawed execution code as the fake devices might not perform very well and might actually be a safety issue in some cases. So what are some of the impacts that a manufacturer could expect? Well, they could see direct loss as in a loss of revenue, as people buy the counterfeits instead of the actual product, or it could be an indirect loss. You could incur a brand damage, especially if people associate the inferior product to the actual product or if there's a significant newsworthy event that people tie back to your product. Second, you could have production overruns where it's your product running your code, it's made from your materials most likely at your expense, but somebody else reaps all the reward. The impacts will direct loss, a loss of revenue because you're paying for someone else to sell your product. Even even if they pay for the materials, you're still losing the sale and your customers are going to experience problems. For example, warranty issues could be a problem for customers who think they've purchased an actual product and then try to use the warranty only to find out that there's no record of the sale. The third is the loss of intellectual property, and this is where someone else steals your code firmware or secrets and uses it to build their own similar product. And now you have competition at little or no cost on their side. And remember, threat actors do not have to subvert factory management to do this. They can go after a very few select employees on the factory floor that are close to the process. Threat actors could be opportunists, they could be a competitor, or organized crime. You could have component substitutions. This is where the contract manufacturer is sourcing cheaper components, but billing you for the higher priced components. And what are the impacts for that? Well, you can have performance issues because these are not the components that you specified with your design. It could lead to a direct loss, a loss of revenues as the device doesn't perform as advertised or expected. It could cause safety issues. You could have like a subpar lithium battery that could have caused problems for the customer by catching fire. It could cause indirect loss, brain damage due to all those things that we just talked about. And, of course, unintentional actions. This covers pretty much everything that's not necessarily a malicious in nature. I've worked in manufacturing industry for my entire career, and factory workers, they're great. They paid on production sometimes, but they may feel pressured to bypass some security measures in order to improve their throughput or to meet their own production targets. And that might affect security, which may or may not be picked up during testing or QA. If it's picked up during testing, then you're going to run into production delays. And if not, then you could have an inferior product going out to market. And all of these have major impacts and we kind of went through them as we went through those threats. But each one of these kind of leans toward loss of revenues or unknown behavior of the device affecting brand damage. Right. And, of course, you need to think about your suppliers, too, because they can make or break you because they are actually an extension of you and their actions reflect on you, not necessarily themselves. Right. Because it's your name is going to be the one who's associated with any issues. Again, you can transfer responsibility, but you can never transfer accountability. Generally, some part of the provisioning process has to be exposed by the OEM to the contract manufacturer. The economics of designing, building, marketing, and selling an IoT widget dictate that not every decision can be made without some sort of compromise. And security, we really exist on that edge balancing functionality with risk tolerance, and it's likely that the cost of manufacturing will tempt some OEMs to seek partnerships in geographies that have lower cost. Oftentimes, these geographies are far away from where the OEM conducts their regular business, making it hard to insure or at least a test, that production practices are always followed. So stable connectivity may not always possible. So the OEM may elect to put an HSM or other component of their provisioning system on site, which works as long as the contract manufacturer can be trusted. Otherwise, you have to design a secure service. Rob Wood authored a white paper called "Secure Device Provisioning Best Practices: Heavy Truck Edition" for the NCC Group. And in it, he outlines several common mistakes that caused provisioning systems to fail. And I'll share several of his ideas with you here on this slide, but I've included a link to his paper and I recommend it to you. Please look at it. He said, one of the first things was shared provisioning secrets using the same secret key in every device. Trust on First Use is another issue, and we've discussed this briefly before, but this is where a trust relationship is formed between unknown parties. For example, when a new device connects. The greatest vulnerability in this process is the risk of a threat actor inserting themselves into it, forgery -- through forgery and a man in the middle attack. Plaintext key provisioning is something else to look for. Secrets are created offline and then add it to the devices. The risk would be if those secrets are not encrypted in transit across the network or at rest while stored on a provisioning USB key or shared directory somewhere. Unauthenticated debug ports is another one that Rob pointed out. This involves physical access to the device. The vulnerability would be if the debug ports are not protected, and we've discussed various ways to do that, which would allow privileged access. And this is bad, especially if there's no authentication required. And insufficient entropy is another one. The strength of the key is built on its ability to be unpredictable. This is like having a password that you think is secure because you increment the number at the end each time you change it. In manufacturing, this would be like using the date time field as part of the key generation process. Key reuse is another one that Rob points out. We've talked at length about different ways that roots of trust can be created and how encryption forms an anchor of trust. And that anchor gets weak when you reuse keys or overuse keys. Remember in DICE, for example, the private device ID key is never exposed outside of the first mutable code. And in TPM, the endorsement key is used only for very specific purposes. In his whitepaper, Rob Wood points out that keys that are used for both signing and encryption can lead to the compromise of the keys themselves. Depreciated cryptography is another one, using obsolete cryptography, cryptographic algorithms, modes or key sizes. You know, those are just asking for trouble, especially after they've already been compromised. Secret algorithms is the last one. And when I studied for the CISSP exam years ago, Kelly M. Elderhand (phonetic), drilled it in my head that open algorithms are more secure than secret proprietary ones because everyone has a chance to independently verify an open algorithm strength. So do yourself a favor and don't try that at home. Don't make your own secret algorithm. Or worse yet, think that obfuscation is cheap and effective solution. It's cheap, but it's not very effective. And hiding something is just delayed discovery. So the IoTSF and their security compliance framework outlines several things that manufacturers can do to address these threats and concerns. Using an escrow service and storing the encrypted IP and offsite location is one. Logging all the devices that are manufactured. Production testing is performed in using a secure boot. That's a third one, as well as making sure that all the production tests and calibration software is removed. Additionally, using a secure location and process to provision devices, not having global secrets because secrets are unique to the devices, making sure that ownership proof is extended along the supply chain, and having an auditable bill of materials. Well, that's it for this lesson. In this lesson, we took a brief trip into the mysterious world of manufacturing and provisioning. We talked about insecure manufacturing issues. We discussed briefly the provisioning risk, and we consulted the IoTSF framework and investigated appropriate security controls to address those risks. I'll see you next time.