The digital age allows us to communicate in ways we have not previously been able to. This has been very empowering; the internet, for example, would not exist; but the digital age also poses new threats which electronic based system designers have to respond to.
How is security being addressed and what’s its positioning within electronic product design specification?
An understanding of locks and keys and the need to protect what is important or valuable to us is gained at an early age; it is part of our general education. Securing property is a familiar concept. It seems all the more surprising therefore, when reviewing requirements for electronic products, that security is often not featured within specifications.
One possible explanation is that need for security is taken for granted. A housebuilder, for example, would expect to fit a front door lock and the house-buyer would not necessarily check it is in the house specification. In that sense it is a ‘given’ but one that needs a very high level of attention.
Questions such as who should fit the locks and who should have the keys emerge; and, one fundamental question when considering each instance, ‘What needs protecting and why?’
| "One common error is to consider security and privacy as one element and in doing so, omit to specify or wrongly specify the security requirements." Dr. Valerie Lynch, AND Technology Research |
Before answering that question there are three very basic definitions and these are:
Security: A thing that guards or guarantees a particular state. It provides a secure condition.
Secure: The description of something that is guarded and protected against attack; reliable and trustworthy. Measures taken to prevent escape.
Privacy: Freedom from intrusion or disturbance. The capacity to control how and what information is communicated.
From these definitions, it can be concluded that whilst a product is connected, security and privacy are two different things. Privacy is about the right to desist from or partake in activity including the dissemination of information. Security is required to protect privacy where appropriate, but not solely. Security also covers measures to ensure reliability and safety. One common error is to consider security and privacy as one element and in so doing omit to specify or wrongly specify the security requirements.
This is a key takeaway. When specifying an electronic product design, consider all aspects of the design that need to be held secure, including the requirements for privacy.
Where to begin? Possibly the place to start is to identify ‘the bad guys’. Who are they and what will they want? Will they want to access data I want to hold private, will they want to cheat a system or will they want to embarrass or damage me? It can be hard to consider these scenarios but in so doing it will simply come down to deciding who is allowed access to what, where to put locks, under what circumstance to raise an alarm and who is allowed to have a key. Complacency and fear both need to be avoided when considering requirements. Too many locks and keys can stop a system being user-friendly and lead inadvertently to complacency. The art is to get the balance right and that will come back to considering the questions posed above.
Developing a security topology, such as shown in the figure, can be useful in getting the balance right. The figure shows a local network which is closed and locked. Security is provided to make it secure and privacy is controlled. Information is, however, transmitted to the internet, and at this point, the network becomes open. The security functions are handed over to the internet protocol handling and this will be okay so long as the privacy of the closed system is operating effectively. The topology also shows other places where locks may be applied and the possibility of imposing a red-line security wall, through which nothing that has not been vetted can pass and from which nothing can escape.
Designing in security
Selecting the most appropriate topology is no simple task, but is the starting point for designing in security. The aim is to cover four key aspects: confidentiality, integrity, availability and attack response. The topology should highlight points at which security needs to be added in order to assure the four key aspects are covered. The choice of an appropriate gateway, for example, will be required to assure confidentiality. What access will be required, which elements are to be open and which closed and what security checks should be put into place.
| "Selecting the most appropriate topology is no simple task, but is the starting point for designing in security." Steve Norman, Renesas Electronics |
Further detailing of the design is necessary to cover the remaining three aspects and decisions as to whether or not to provide security through software or hardware also have to be made. To support integrity, custom designed security chips can be incorporated in the design. These chips cannot be re-programmed and can be used to implement red-line security. Software algorithms can also be effective but care has to be taken that they cannot be tampered with. Other software techniques such as cross-checking the actions of independent functions and applying check-sums to data blocks and back-ups adds to integrity. Ensuring that a system’s function remains available requires monitoring. Many wireless systems have been subject to ‘Denial of Service’ (DoS) attacks, and techniques such as checking the signal-to-noise ratios, limiting numbers of requests and checking for bad data have been developed to deal with such attacks. Furthermore, if the system is to monitor for attacks, decisions will need to be made about how to deal with them. Wiping memory or locking down functions may seem like overkill, but may be necessary. As in real-life, sometimes having locks and keys is just not enough and the overall system requirement and design has to be robust enough to cater for this.
The Renesas Synergy Platform has been designed with security in mind. Built on highly scalable ARM Cortex-M microcontrollers, Synergy provides a complete embedded hardware and software platform, including the qualified, production-grade Synergy Software Package (SSP) for guaranteed operation, which is fully integrated and maintained. Additionally, designers can write their applications at the package API level, meaning time traditionally spent on repetitive, non-differentiated low-level coding can be spent on adding differentiated features.
Synergy microcontroller devices (referred to by their family names S1 (low power), S3 (high efficiency), S5 (high integration) and S7 (high performance) in the figure) with in-built hardware encryption algorithms required for generating locks and keys, are available as are functions to ensure the integrity of data within the supplied
The availability of these facilities means that the embedded system designer can more easily incorporate the necessary security features from the beginning, and is not left with the difficult task of trying to ‘add-in’ security to a fundamentally un-secure architecture.
Here is another key takeaway. The most important point for an embedded engineer is to design-in security from the start. Retrofitting security is unlikely to be as effective.
The end goal can only be reached once a system is proven as ‘Launch Ready’. Evaluating the security of the system is a part of this process but more generically the designer must consider the overall confidence level and the evidence that backs this up. Using a platform such as Synergy, from Renesas, means that designers can gain momentum through ‘buying in’ functionality rather than looking to develop it all themselves.
Want to learn more about Renesas Synergy strategies and tools for addressing security in your design? Click here.
| Author profile: Dr Valerie Lynch is CEO of AND Technology Research & Steve Norman is Manager of Global Ecosystems at Renesas Electronics |
