Secure Products from Beginning to End

An early understanding of product security vulnerabilities is necessary to adequately budget processing power and memory resources.

By Brian Neill

Many hidden issues must be addressed when designing a secure product. Although cryptography is an important building block for security, algorithms on their own cannot guarantee security. Embedded-product designers must consider the security issues and needs for the entire life cycle of their products ranging from design, manufacturing, and operation to end of life. Fundamentally, security is about protecting the value of an asset. This includes the device itself as well as the data that it processes or stores, its configuration, and its appropriate operation. To ensure that the device is equipped with suitable resources for the security safeguards needed to protect its value, many often-obscure security issues should be addressed up front during product design. Such issues range from choosing the right cryptography, designing products that can be safely manufactured by a third-party contractor, and having an end-of-life product strategy that will protect future sales.

Design Security at the Start
At the outset, developers should consider all of the possible issues and safeguards needed to prevent or react to attacks. The most effective safeguards are those that are layered with other technologies to address a defined set of product vulnerabilities. For example, can people steal data from the device? Is it likely that someone can tamper with the product and cause it to misbehave (e.g., make random calls or misreport information)? Can the device be copied and reproduced?

These are some of the questions that need to be addressed during product design. If they aren’t, one of them will likely emerge in a fielded product. That product will then require a security retrofit. Because products tend to be efficiently engineered from the start, it can be difficult to retrofit security after a product has been fielded. Logistics aside, fielded designs will probably be scarce on the extra resources needed for new security safeguards.

Too often--as in the case of anti-cloning controls--manufacturers try to prevent the theft of intellectual property only after a problem arises and product margins are being eroded. This sequence of events takes the design decision away from the engineer and puts it into the domain of a business decision-maker. That individual weighs the costs of adding memory and processing power against perceived shrinking product margins. For this reason, problems due to counterfeiting tend to be ignored until some critical threshold finally requires the cloning problem to be addressed. Even then, it’s difficult to make a case for raising production costs and the product’s bottom line. It’s always better to make a case for security in the beginning--before device cloning becomes a problem that requires an executive’s attention.

Electronic Anti-Cloning
In the world of electronics, “anti-cloning” is a term applied to the technology safeguards used to protect against intellectual- property theft. Hardware designs can be stolen through reverse engineering, overproduction, and counterfeiting. Attacks also can occur at the firmware layer to perform aftermarket product “up-revs.” Here, an attacker turns a cheaper version of a fielded product into a more expensive, fully featured version.

Can anti-cloning safeguards really protect products? Yes, assuming that expectations are correctly set. It’s important to realize that electronics counterfeiting is a business. A successful anti-cloning safeguard will increase the cost of a counterfeit business operation without causing the original product manufacturer to incur the increased cost themselves. Completely preventing IP theft is practically impossible. But it is possible to design products that are so difficult and costly to copy that the product is effectively an unsavory target for theft. Illicit businesses need margins as well.

According to estimates from the Association for Counterfeit and Grey Market Abatement (www.agmaglobal.org), one in ten electronic products sold on a global basis are actually counterfeit. Protecting products from lost revenues due to counterfeiting is the responsibility of the product design team. Fortunately, products exist to help combat electronic counterfeiting. From the device perspective, protecting against counterfeiting attacks usually amounts to hiding and protecting secrets within the product. These “secrets” are used with cryptographic techniques to protect critical data or operations within the device. As long as these keys remain secret, the safeguard is effective.

Hiding Secrets
Can the product protect secrets in silicon? If the product is a mobile phone and the developer is designing around the Intel® Wireless Trusted Platform (WTP), the native WTP application programming interface (API) can be used to safely store secrets. It will use methods that would require an attacker to compromise the WTP processor itself. While an attack isn’t impossible, it significantly raises the cost of a successful attack against a mobile device--especially if the “secrets” being protected are different for every device.

If a specialized trust processor isn’t available, other secure components are available from various third-party semiconductor companies. These components could be added to the product’s board design. Otherwise, the product will require the end user to remember a secret or employ an obfuscation technique to hide pieces of secrets in various places around the device. Some security service companies have sophisticated techniques for key obfuscation with this intent.

In the world of security, the word “secret” is almost interchangeable with the term “cryptographic key.” The former is often used to generalize types of cryptographic keys. When talking about the specifics of protecting secrets, various types of cryptography are employed. Some of them will be addressed later in this article when cryptography’s role as a security building block is examined.

Secure Manufacturing
Products that hide secrets also must address the realities of manufacturing environments in today’s world. Simply put, a product isn’t likely to be manufactured by the company that designed it. Many companies contract third-party manufacturers to maximize profit margins. Typically, these types of companies are in a different geographic location than the original equipment designer. While this approach may be good news for an embedded product’s bottom line, it poses security issues--especially if there’s a concern of counterfeiting, cloning, or illicit overproduction activities to supply grey markets.

The secrets and unique cryptographic identities that are used to protect against cloning attacks in the field need to be injected into the device at manufacture time. But contract-manufacturing sites are the most likely places that keys and identities are exposed to counterfeiters. It’s common for product design and engineering teams to give their designs to the manufacturing logistics group without a plan or provisions for secure manufacturing. Given the realities of time-to-market schedules, the easiest and most insecure key logistics solution is often implemented at the last minute: Keys are sent in bulk to offshore contract manufacturers using an unprotected format like e-mail, FTP, or optical media. Thought should be devoted to the security gap between engineering design and manufacturing teams. Special security features may then be added to the product design. Alternatively, specialized manufacturing systems could be designed specifically for secret key injection.

Secure End-Of-Life Strategy
Security risks can be exposed even years after a product has been manufactured. As a result, developers should consider what could happen to a product at the end of its life. The underlying question is reminiscent of firmware cloning: Can an old product be easily refurbished and compete with new innovative products at a later time? Anti-refurbishing strategies are a sensitive topic. In Europe, for example, recent environmentally friendly laws have banned mechanisms from being added to printer consumables that would otherwise prevent or limit the possibility of refurbishment.

Embedded products increasingly use general-purpose computing platforms--complete with an operating system--that can be reconfigured by re-flashing firmware. This approach is convenient for field upgrades. Yet it also means that the product can be re-tasked for other purposes using firmware that was intended for other products. In essence, it may be possible for old products to be refurbished using firmware from new products, thereby eroding sales of new and innovative technology. If a product has been designed with security and cryptography in mind, however, it’s relatively easy to add a digital signature to firmware upgrades. This feature will prevent unauthorized retrofits and up-revs. Keep in mind that this feature also is easily defeated without care and attention given to the product’s holistic security design.

Engineering with Cryptography
Most of the design considerations mentioned previously will use cryptographic techniques to build safeguards that will protect the product. This statement implies that an embedded device has the required resources to perform the mathematics of cryptography. Here, some of the more popular cryptographic algorithms will be contrasted with respect to benchmarks on an Intel XScale® processor. While cryptography isn’t the end goal of security, it is one of the fundamental building blocks of secure products and systems. It’s therefore worth knowing how different cryptographic algorithms behave with respect to processing requirements and memory.

A cipher suite is a set of complementary cryptographic algorithms that are selected to work together to implement safeguards. Typically, the suite consists of a secure hash function, a symmetric key cryptographic algorithm, and a public- key cryptographic algorithm. Cipher suites should be chosen according to the level of security that can be afforded with respect to budgets for processing time and memory space. Because every cryptographic algorithm is different in effective strength, the key size for each cipher in the suite must be adjusted to match the others accordingly.

For example, the National Institute of Standards and Technology’s (NIST’s) Advanced Encryption Standard (AES) is a symmetric key cipher. Elliptic Curve Cryptography (ECC) refers to a family of asymmetric (public-key) schemes. Both ciphers have complementary properties and are used in conjunction to implement security. Yet each cipher has a different strength. With a 128-bit key, AES has the same effective strength as an ECC algorithm that uses a field size of 256 bits. RSA is another type of public-key cryptographic algorithm. AES-128 matches RSA with a 3072-bit key. Higher bit counts generally correlate to greater processing requirements. As a result, careful cipher-suite selection is critical to efficient embedded-product design.


Table 1 gives some relative benchmarks of various ciphers running on an Intel XScale processor. Notice the increasing computational requirements of the public- key-based digital-signature operations for ECC and RSA. These benchmark gaps grow as the key sizes get larger. For further information and algorithm comparisons, check the NIST web site (for a list, NIST and other references refer to Certicom’s ECC FAQ: www.certicom.com/index.php?action=res,ecc_faq). A subset of the comparison information available from NIST can be found in Table 2. It’s also valuable to review the National Security Agency’s (NSA’s) “Suite B” algorithms for further recommendations and comparisons based on the U.S. government’s “crypto modernization program” (www.nsa.gov/ia/industry/crypto_suite_b.cfm).

As every security engineer will stress, cryptography should be purchased from cryptographers. All too often, engineers get caught up in the cloak-and-dagger novelty of writing their own cryptographic- algorithm implementations. From a security engineer’s perspective, however, there are a plethora of challenges that extend well beyond cryptography when designing a secure product. Battling cryptographic implementation flaws--if they’re even noticed--adds time and complexity to project implementation phases. Those resources would be better used for high-level security testing and analysis. By obtaining quality cryptographic- algorithm implementations, engineers can more easily treat ciphers as building blocks to address higher-level security issues. They also will increase their likelihood of addressing such higher-level issues.

Designing security into products is a very comprehensive undertaking. Threats to the product need to be identified and addressed during product design so that safeguards can be properly budgeted in terms of device processing power and memory. Security also must be addressed during phases of a product’s life--both before and after fulfilling its intended purpose. In these phases of the product life cycle, neglecting security will result in hidden vulnerabilities that have real impact on the success of an embedded product.


Brian Neill, Certified Information Systems Security Professional (CISSP), is a Product Manager at Certicom Corp. Prior to his current role, Neill was a member of Certicom’s Professional Services team, helping customers to engineer security into their systems and products. Neill received his B.Math degree from the University of Waterloo (Canada) in 1999.