Making Embedded Processing Development Easy - part 6 -

Making Embedded Processing Development Easy – part 6


Welcome to a six-part series on 'Making Embedded Processing Development Easy'. We’re on the sixth and final installment created to introduce you to the fundamentals of embedded software design and considerations to aid with embedded processor design.  This series is derived from the expertise of embedded processor software experts from Texas Instruments and is meant to provide an objective view of easing software design.  

This week’s edition is brought to you by Erik Welsh, a security architect in TI’s Application Specific Products Organization.
Q:  I’m not sure I need to secure my embedded design?  If I do, how do I begin and which type of security should I enable?

A:   Security can be a very important part of an embedded design, but in order to determine if you need security and how secure the embedded design must be, you should ask yourself some fundamental questions:

  1. What do you want to protect?
  2. Who are you trying to protect against?
  3. What is the cost if the information you’re trying to protect is compromised?

Here are some examples of embedded designs that require security:

  • Point of sale terminals need to protect both the storage and communication of credit card information from end users, terminal operators, service technicians and organized crime.
  • Media players must secure rights management of content and copy protection from content pirates.
  • Power metering applications require security to obtain accurate measurement and transmission of power data from individuals or organizations seeking free power.
  • End user computing, voice and data communications infrastructure applications use secure communications for the end users of the equipment to protect against identity thieves and individuals or organizations trying to intercept communications.

Once you’ve determined exactly what you’re trying to secure on your embedded design and the costs associated with that information, then you can determine what security features best fit your design.  The diagram below outlines some common security features that are supported by embedded systems.  Note that some of the security features, such as secure run time, are much more expensive to implement than others, such as HW cryptographic acceleration.  

Let’s talk about a few of these security features in more detail:

1. Cryptographic acceleration is performed by dedicated hardware within a device that frees the host CPU to perform other tasks. Cryptography acceleration can be used for many different functions within a system.  One key use is to protect data transmitted through insecure network with a secure socket layer.  There are several cryptographic algorithms that can be used to accomplish specific security goals:

  •  Encryption algorithms
    • Used to ensure confidentiality.  An encrypted piece of data is only visible to an entity with the appropriate key.
    • Example algorithms:  AES, DES / 3DES
  • Hashing algorithms
    • Used to create a digest of a larger piece of data.
    • Example algorithms:  MD5/SHA-1/SHA-224/SHA-256/HMAC
  • Authentication algorithms
    • Used to ensure authenticity.  The source of a signed piece of data can be verified.
    • Example algorithms:  RSA, DSA, ECDSA, ECIES
  • True random number generator
    • Generates random numbers that meet industry / government standards for randomness.

2. Secure boot uses a hardware based “root of trust” to establish a known good starting point for device operation.  This allows the device to prevent external entities from modifying customer-developed algorithms; to stop unauthorized users from misusing the customer’s system; and to protect the device operation by preventing insertion of malware, reverse engineering and system cloning.  There are three features of secure boot that offer different types of protection but have different costs and requirements:

    • Intellectual property (IP) protection does not allow copying of the code sitting in external flash.  By encrypting the code and data contents of the external boot image, this protects the software investment that went in to the embedded system.
    • Takeover protection allows the processor to only run the software you’ve programmed on it.  By using non-volatile one-time-programmable memory within an embedded device, the device can establish a hardware based root of trust to only run software that is authorized.
    • Open manufacturing protection gives an embedded system design company the ability to protect their secrets from their third party manufacturers.  By having a shared secret between the embedded system design company and the device, the third party manufacturer is able to produce the system but unable to see any sensitive information.
3. Secure run time protects your secure algorithms and data from the rest of the software in the embedded system.  Some examples of secure run time options include:
    • ARM TrustZone is a proprietary secure run time system from ARM that is used to protect code and algorithms from the rest of the software in the system.  It provides additional HW extensions within the ARM CPU create both secure and non-secure worlds.  It is managed through software APIs within read-only memory or third-party secure middleware component (SMC).
    • Secure DMA uses dedicated DMA resources for security and is used to transfer sensitive data securely within the system.
    • Secure storage is used to store information securely in external memory and uses device- specific information to encrypt / decrypt information.  In some cases, the CPU can use secure storage but cannot see key used to encrypt / decrypt information.
    • Secure watchdog timer is used to ensure that secure software executes smoothly.  It uses a secure clock source, and it’s similar to a traditional Watchdog Timer, except it only accessible in the secure world.

As you learned, there are many options for enabling software security on your embedded design.  It’s simply a matter of evaluating your design needs and choosing the one that works best for you.

We hope 'Making Embedded Processing Development Easy' helped generate some ideas and tactics to make embedded design easier for you.   If you ever run into design questions and considerations in the future, please feel free to visit the online TI e2e community, specifically our Embedded Software Forum, to get 24/7 support.

Read other parts here: Making Embedded Processing Development Easy

About the author:
Erik Welsh is a security architect in the embedded processing team at Texas Instruments and an active leader in TI’s security community.  He has been involved in all aspect of TI's embedded processing security solutions, creating the security hardware that is in many of TI's processors, as well as the documentation and support collateral to make security easier to use for TI's customers.  Erik has worked both within the SoC design and applications groups within TI and is currently leading the effort to enable security features on TI's next generation processors.  Erik received a bachelor’s and master's degrees in electrical engineering from Rice University.

If you found this article to be of interest, visit the Micocontroller Designline where you will find links to relevant technical articles, blogs, new products and news.

You can also get a weekly newsletter highlighting the latest developments in this sector – just Click Here to request this newsletter using the Manage Newsletters tab – if you aren't already a member you'll be asked to register.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.