Transport Layer Security

Leave a comment


Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both of which are frequently referred to as ‘SSL’, are cryptographic protocols designed to provide communications security over a computer network.[1] They use X.509certificates and hence asymmetric cryptography to authenticate the counterpart with whom they are communicating,[2] and to negotiate a symmetric session key. This session key is then used to encrypt data flowing between the parties. This allows for data/message confidentiality, and message authentication codes for message integrity and as a by-product, message authentication.[clarification needed] Several versions of the protocols are in widespread use in applications such as web browsing,email, Internet faxing, instant messaging, and voice-over-IP (VoIP). An important property in this context is forward secrecy, so the short-term session key cannot be derived from the long-term asymmetric secret key.[3]

As a consequence of choosing X.509 certificates, certificate authorities and a public key infrastructure are necessary to verify the relation between a certificate and its owner, as well as to generate, sign, and administer the validity of certificates. While this can be more beneficial than verifying the identities via a web of trust, the 2013 mass surveillance disclosures made it more widely known that certificate authorities are a weak point from a security standpoint, allowing man-in-the-middle attacks (MITM).[4][5]

The Internet Protocol Suite places TLS and SSL as tools into the application layer, while the OSI model characterizes them as being initialized in Layer 5 (session layer) and operating in Layer 6 (presentation layer). The session layer employs a handshake using an asymmetric cipher in order to establish cipher settings and a shared key for a session; the presentation layer encrypts the rest of the communication using a symmetric cipher and the session key. TLS and SSL may be characterized to work on behalf of the underlying transport layer protocol, which carries encrypted data.

TLS is an Internet Engineering Task Force (IETF) standards track protocol, first defined in 1999 and updated in RFC 5246 (August 2008) and RFC 6176 (March 2011). It is based on the earlier SSL specifications (1994, 1995, 1996) developed by Netscape Communications[6] for adding the HTTPS protocol to their Navigator web browser.

Why do embedded systems store server’s public certificate in ROM?

Leave a comment


In the home automation scenario, smart gateway can bridge the many smart devices with Internet. In many cases, a server’s public certificate is stored in the embedded system’s ROM during manufacturing.

For example, in case of AlertMe gateway, each gateway device is manufactured with a unique ID. In addition, it also holds the public certificate of the AlertMe servers in ROM. On first boot, the gateway device generates a random RSA key pair, connects to the AlertMe servers, verifies the server’s identity (using the ROM public certificate), and gives the server its random public key.

My question is, since in the SSL/TLS connection the server will send its certificate to the gateway, why does the gateway have to store a public certificate in the ROM, before its first boot. If, like what it says, it is for the verification purpose, how does the gateway verify the server’s identity? Does it just compare the gateway’s certificate in the ROM with server’s certificate sent at SSL handshake? Can’t the embedded system contact the CA, to verify the identity of the server?

Moreover, on first boot, gateway will generate RSA key pair, and then the certificate. Where is the safest place in the Linux based gateway/embedded system to store the key?

2 Answers

For your question why the server certificate is saved in the ROM:

The saved certificate is checked against the certificate sent back by the server. This is a correct assumption from you. Therefore only one server is trusted at this moment.

You ask why the device does not simple connect to a CA. This would be another way to work. But even then the CA root certificate must be embedded in the ROM. This is needed because else how would you connect to the CA? You need also SSL/TLS to connect to the CA because else all the PKI would be senseless. So at least one certificate must be embedded in ROM.

As a slight side node: embedded developers are, in general, terrible at security. I did a whole presentation at a security conference on some of the more egregious stuff I’ve seen. If you’re adopting an embedded device that will sit in a privileged position in your network, or that will hold sensitive information, make sure you get it independently tested, and ensure that you place appropriate secondary controls (e.g. a hardware firewall) between it and your internal network. –  Polynomial Jun 21 ’13 at 8:26

Hardening PKI to Address the IoT and Mobile Devices

Leave a comment


PKI Primer

Public Key Infrastructure is a fairly complex set of technologies, people, policies, and procedures, which are used together to request, create, manage, store, distribute, and (ultimately) revoke digital certificates – binding public keys with an identity (such as an organization, address, personal, or email).

These certificates are the staple solution today for verifying that a public key belongs to an individual.  These technologies are used in conjunction with everything from web-based browser authentication to e-commerce and identity management for access to government and commercial e-services.

The impetus for PKI occurred in the 70s and in reality before the Internet was the Internet. Conversion of PKI schemes into successful commercial operation has been a relatively slow moving process.  In reality PKI’s progress, as an industrial identity control scheme has been slow and challenging, hampered by its complexity and vulnerabilities.

Today, binding a public key with a respective user identity occurs via a Certificate Authority (CA).  The CA is responsible for the issuance of digital certificates as a trusted third party by both the owner of the certificate and the parties relying upon the certificate.

Several trust anchors are involved to authorize the binding of public keys with user identities.  User identities are unique within each CA domain and third party Validation Authorities (VAs) can provide a validation service on behalf of the CA.  Registration Authorities (RAs), Certificate Revocation Lists (CRLs) and Online Responders (Online Certificate Status) further complicate this picture, ensuring that the validity of signatures signed with a private key cannot be legally denied by the signer (non-repudiation)[1] and  valid – that the certificate is specifically bound to an individual in a way that is legally recognized, that each certificate’s signature is valid, the current date and time are within the certificates validity period, and that the certificate(s) have not been corrupted or malformed all the way up a certificate chain to the root certificate.

PKI for M2M and IoT

Further complicating this picture, conventional PKI solutions typically require manual interaction for the certification of a public key during an identity check. While this is not a substantial issue with e-mail encryption, (the participants are natural persons), this becomes problematic with machine-to-machine (M2M) based authentication where the embedded systems are machines, which require automatic processing of certification requests.  How can any of these interactions be trusted without verification? Currently, as the only tool available for identity management, PKI as a scalable identity infrastructure has proven impractical to secure the billions of mobile devices (the Internet of Things (IoT), as well as the networks they utilize.  There has been an explosion in the number of required certificates, as each device requires it’s own unique certificate.  Moreover, many of these M2M networks are distributed and decentralized, potentially having to utilize many disparate CAs.  The framework breaks.  This liability means it is imperative to securely automate certificate provisioning, renewal, and revocation processes.

Enter Guardtime and Keyless Signature Infrastructure (KSI)

At Guardtime, we believe that in order to seriously delivery security to users using this framework, we have to understand the weakness of the tools and their components.

Guardtime and Keyless Signature Infrastructure is a significant way to strengthen PKIs weak areas without increasing costs.  With the pervasiveness of today’s threats, the Internet is now faced with a fundamentally grave situation from the multitude of attack vectors that can affect PKI security (phishing, viruses, malware, identity data losses, misconfiguration, etc).

The security community can no longer afford to blindly implement PKI technologies just because it’s the only tool in the toolbox.   PKI must be upgraded to address its scaling challenges, trust anchor, evidence portability, and administration liabilities.

What is KSI?

KSI is a technology invented by Guardtime to provide massively scalable strong data integrity, tamper evidence and backdating protection for literally any kind of digital asset. KSI provides verifiable guarantees that data has not been tampered with since it was signed.

A Guardtime signature provides proof of time, identity, and authenticity without the reliance on cryptographic keys and secrets, or trust anchors like systems administrators or Certificate Authorities.  Guardtime signatures can be verified in real-time, providing continuous integrity monitoring for literally any kind of digital asset or data object.

KSI Compliments to PKI

PKI has been tailored to enable secrecy, obfuscation and identity verification but it does require a large amount of trust be vested in one or more trust anchors; from the public Certificate Authorities to internal Certificate Management Systems and the Certificate Revocation Lists themselves.  KSI can be used to secure a PKI infrastructure and/or enhance CRLs by automating Certificate Revocation.

KSI does not require trust authorities and facilitates automated verification.  The signatures are devoid of any secret data and can be used to mathematically verify the integrity of the data, providing non-repudiation, while also protecting against backdating.

PKI vendors are developing CA suites to address the scalability and portability challenges associated with automated certificate management for large scale (such as IoT and M2M) identity management.  Guardtime can assist these PKI platform vendors to ensure the coherence and real-time resilience of their platforms, as well as strongly backstop the authenticity of identities on their ever-growing networks in a cost-effective, scalable, and compliance-related manner.

Securing Public Key Infrastructure Components with KSI

Guardtime’s Videri Gateway is the fundamental component needed to secure a complex infrastructure such as PKI.  Videri is a KSI-standards based authentication gateway (appliance) that can be used to ensure critical PKI application, credential and configuration integrity.

Videri is real-time application and integrity monitoring and validation for Public Key Infrastructure platforms.  PKI critical application, security, and static configuration components can be validated in real-time to ensure tampering and malicious attack of the infrastructure has not occurred.  Moreover, all audit and event logs associated with each PKI component become tamper evident with proveably secure and mathematically verifiable methods.  Videri integrity validation and intelligence can be exported in real-time to your Security Intelligence and Event Management (SIEM) system, or Guardtime’s GuardView SIEM for real-time alerting and dashboard management of critical PKI components, applications, subsystems, configuration files, or credentials.

KSI can be used to secure literally any kind of hierarchical CA model.  Where the CA consists of clearly defined parent/child relationships, child subordinate CAs are certified by their parent CA-issued certificates, which bind a CA’s public key to it’s identity.  Each of these relationships requires careful configuration management; planning, and the creation of operational and administrative dependencies with trust anchors that build up to the root CA .  Operational dependence on these child CAs for mission critical functions means real-time integrity monitoring is a must.  A root CA is the important point of trust in an organization and subordinate CA are created to provide administrative benefits from the root and are set up practically to separate usage, organizational division, geographic divisions, load balancing, and backup and fault tolerance.  These configurations and associated policies benefit from KSI integration.

KSI can be implemented into these systems to secure and provide real-time continuous integrity monitoring of all critical CA management applications such as Certificate Services for a particular PKI deployment.  These services include any CryptoAPIs and Cryptographic Service Provider (CSP) dependencies underlying the PKI system for cryptographic operations and private key management, as well as signing and verifying the Certificate stores themselves, which are responsible for storing and managing certificates in the enterprise.

Moreover, with the increasing use of software-based CSPs, private keys and cryptographic operations are not well isolated from the server they run on and the operating system.  With this vulnerability, application or OS tampering are common exploitation approahes to expose keys and is in fact one of PKIs most glaring fundamental vulnerabilities.  With KSI and Videri, configuration and application baselines can be monitored in real-time to ensure that software-based CSPs are secure with real-time tamper evidence of dependent applications and the OS components themselves in the event of attack.

For CA installation, KSI is implemented to sign and provide real-time validation to CA configuration files, security-related files responsible for permission management between PKI subsystems, and to ensure tamper detection of any certificate templates used by the CA and infrastructure for Certificate Services.  These include all Certificate Server services, Public Key Group policies, Issuer Statements, Certificate Database Logs and their associated configuration files (and dependencies) as well as common web enrollment applications associated with a PKI deployment.

[1] A word on liability.. It is important to consider that the Internet’s increasing reliance on PKI has in fact developed a reliance on CAs.  CA vendors have NEVER paid out in the case of fraud or stolen credentials or identities.  Looking under the hood, CAs agree that when pressed on their warranty programs, there is no substantial backing to a claim if a certificate is used maliciously.  The result:  organizations using PKI have outsourced their trust to authorities that simply have no skin in the game, nor will guarantee their security.  Where is the accountability?

Digital Certificates vs Digital Signatures

Leave a comment


Digital Signatures

A Digital Signature is a method to ensure data authenticity. A digital signature is created by generating a hash (message digest) against the data and then encrypting this digest using the cryptography (public or private) key. This signature is then appended to the data.

Once the recipient has received the data + signature they generate a hash against the data, as well as decrypting the signature using their cryptography (public or private) key. These digests are then compared to ensure data authenticity.

Digital Certificates

A Digital certificate is a form of electronic credentials. Digital certificates are issued by a Certification Authority (CA) and are used to encrypt and sign digital information. Digital Certificates typically contain the Owner’s public key/name, expiration date of the public key, Name of the issuer (CA), Serial number and the Digital signature of the issuer (CA).

Reference :

Securing PKI: Introduction

Leave a comment


This topic has not yet been rated Rate this topic

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012

Attacks against computing infrastructures, whether simple or complex, have existed as long as computers. However, within the past decade, increasing numbers of organizations of all sizes, in all parts of the world have been attacked and compromised in ways that have significantly changed the threat landscape. Cyber-warfare and cybercrime have increased at record rates. “Hacktivism,” which attacks are motivated by activist positions, has been claimed as the motivation for a number of breaches intended to expose organizations’ secret information, to create denials-of-service, or even to destroy infrastructure. Attacks against public and private institutions have become ubiquitous, with the goal of exfiltrating the organization’s intellectual property (IP).

When looking at your environment, an appropriate mindset is to assume that you have already been breached or a breach will occur at some point. No organization with an information technology (IT) infrastructure is immune from attack, but if appropriate policies, processes, and controls are implemented to protect key segments of an organization’s computing infrastructure, escalation of attacks from penetration to complete compromise might be preventable. The principles and recommendations provided in this document are intended to help secure your environment against external attackers and misguided or malicious insiders.

The information and recommendations provided in this document are drawn from a number of sources and derived from practices designed to protect Public Key Infrastructure (PKI) installations against compromise. Although it is not possible to prevent attacks, it is possible to reduce the attack surface and to implement controls that make compromise much more difficult for attackers. This document presents some of the most common types of vulnerabilities observed in compromised environments and most common recommendations to improve the security of PKI installations.

While many of the recommendations found in this document are specific to PKI installations that utilize Active Directory® Certificate Services (AD CS) as a technology platform, many of the recommendations are also vendor agnostic and can be implemented in any PKI deployment.

If you operate a PKI within an Active Directory® (AD) environment, it is strongly recommended that you also read Best Practices for Securing Active Directory. Since the security of the AD CS installation is in many respects directly dependent on the security of the Active Directory® installation, an understanding of the avenues to compromise and methods to secure Active Directory® will greatly enhance your ability to secure your PKI deployment.

Much of the content of this document is derived from knowledge gained from years of PKI and Active Directory® assessments performed by numerous Microsoft information security professionals. Additional recommendations are gathered from extensive experience gained from operating numerous PKIs at Microsoft, both for external and internal uses. Although individual customer data was not used to create this document, the most commonly exploited vulnerabilities identified from our assessments and the recommendations to improve security of AD CS installations are utilized. Not all vulnerabilities are applicable to all environments, nor are all recommendations feasible to implement in every organization.

Within Microsoft, numerous organizations provide consulting services for PKI. Depending on the needs of the customer, an engagement may include PKI design, implementation, compromise response, or assessment for health and security. Microsoft provides customers with recommendations based on their organization’s unique characteristics, practices, and risk appetite. PKI assessments performed internally at Microsoft and those of our customers have contributed to the recommendations in this paper.

This paper is not intended to address all potential security issues across PKI, but rather is focused on providing actionable content for areas in which Microsoft has seen deficiencies while performing assessments over several years with many customers. Specifically, this document does not attempt to provide recommendations for other Active Directory® Certificate Services roles such as Network Device Enrollment Services (NDES) or Online Certificate Status Protocol (OCSP).

Within any PKI regardless of the technical implementation, a number of components and actors are present. This brief introduction will help provide context and definition of terms used throughout this whitepaper.

Subscriber/End Entity – The person or computer listed as the subject in a certificate. In the context of this whitepaper, an End Entity certificate is any certificate issued to a person or computer.

Relying Party – A user or system that consumes the certificates generated by the PKI. Examples of relying parties would be users of web browsers visiting an SSL protected web site, a VPN server authenticating a remote user, or a computer validating that an executable is signed correctly before running it.

Certification Authority (CA) – Broadly, a CA is a set of systems and practices used by an organization to issue and manage certificates. For the context of this paper, the CA will be the system responsible for signing certificates and running CA software such as Active Directory® Certificate Services.

Registration Authority (RA) – A CA may delegate some of the tasks related to verifying identities and processing certificate revocation requests to a Registration Authority (RA). An RA could be a person performing manual checks or a system automating the required validation checks. The CA will accept certificate requests processed by the RA and sign them, trusting that the RA has done the proper validation.

PKI Repositories – A PKI repository is a location accessible by relying parties where PKI information is stored. This information could include certificates, revocation information, or information regarding the policies of the PKI. For example, this information can be posted to internal or external web locations.

For a glossary of terms used in this whitepaper, refer to Securing PKI: Appendix D: Glossary of Terms.

For basic information about PKIs, refer to Securing PKI: Appendix E: PKI Basics.

Maintaining the trust of relying parties is an integral component to running a PKI. If a relying party does not know the policies a PKI uses for governance, or the PKI has no formal policies, they cannot make an informed decision to trust that the certificates issued by the PKI are correct. To facilitate trust, a PKI must be operated with some level of oversight, and with policies, standards, and procedures in place to control how the PKI is managed. The level of oversight required will vary depending on the intended use. For example, a PKI trusted and used internally at a company to issue certificates for wireless network authentication does not need the same amount of oversight as a PKI used to issue SSL certificates trusted by default by all major web browsers. Governance is not a topic unique to PKI- other critical infrastructure systems should also be run with formalized change control and oversight.

Whenever a new piece of technology is introduced to an environment, it should be for a defined business reason and PKI is no exception. In many cases, we have observed a PKI introduced at a company in support of a specific solution or product. For example, a PKI could be constructed to provide end user certificates in support of secure remote access. In general, PKI can be thought of as an enabler for providing solutions for the following high-level business requirements:

  • Data Encryption – PKI provides several solutions for securing data in transit and at rest. PKI is commonly included as a part of a solution to securely exchange data between partners, customers, or internal sites. Common implementations include using certificates to enable Transport Layer Security (TLS) for secure transmission of data, S/MIME certificates for sending encrypted email, and Encrypting File System (EFS) certificates to encrypt files on a workstation.
  • Authentication – PKI is often used as a solution to provide high-assurance authentication credentials. Common implementations include issuing certificates for private keys that reside on a smart card for multifactor authentication and issuing certificates to computers and devices for network authentication.
  • Data Integrity – PKI can be used to ensure that critical data has not been altered and that it comes from a trusted source. One common implementation is code signing, where files are signed by the developer when a software package is released. Another example is electronic document signing, where certificates can be used to allow a person to “sign” a document to show the document has not been altered since the signature took place.

For a PKI deployment to be successful, several factors must be in place:

  • Understanding of Business Requirements and Objectives – Like any investment made by an organization, the business requirements and value provided by the PKI should be well understood prior to implementation. Understanding how the PKI supports the business, what processes it supports or enables, and any externally imposed requirements allows you to make informed decisions on the level of risk you are willing to accept when designing the system. For example, an internal PKI supporting wireless LAN authentication will be designed and secured differently than a PKI built for issuing SSL certificates that are trusted by external organizations.
  • Risk Assessment – A proper risk assessment and threat modeling should be performed prior to deploying a PKI. A risk assessment will determine the level of security and the investment that should be made in the PKI.
  • Executive Support – As with any other large-scale IT project, support from executive management is crucial in the deployment of a PKI that meets large-scale needs. A properly implemented PKI often represents a significant investment, both in capital and human resources. Executive management needs to have a clear vision of why PKI must be designed and operated differently from commodity IT services, as well as have a clear understanding of the business requirements the PKI helps to satisfy.
  • Planning and Foresight – A PKI deployment is often unique from deployments of other technologies, because more stringent security controls are required for the deployment to succeed. A PKI deployment also requires the development of rigorous operating procedures. For a PKI to succeed, careful planning must occur to ensure that the policy, procedures, and technical implementation meet the needs of the business, both now and into the future. If a PKI is configured incorrectly, frequently the only good solution is to start over and implement a new system. With proper planning, you will be able to avoid costly rework or compromise.

    When planning a deployment, pay special attention to any shorter term (12-18 months) uses of the PKI. If you do not plan at the very beginning to accommodate known future uses, you may end up setting up parallel infrastructures in the future, or be forced to modify the existing infrastructure in ways that make it more complex and costly to operate.

  • Defined Policies – Prior to implementing any certification authorities or issuing certificates, define and agree upon the policies which govern the use of the PKI. Applications either inside or outside your environment will be dependent on the PKI, and these policies will provide clear guidance on what to expect for topics such as certificate issuance, security, disaster recovery, etc. Policies do not need to be overly complex, but it is critical to develop and follow them.
  • Ongoing Governance and Oversight – Governance plays a significant role in a successful PKI because a PKI is not a static system. There will likely be ongoing changes within your environment that will drive operational or security changes to your PKI. Proper governance ensures the risk of any changes introduced are well understood, carefully considered, and are well communicated to the community of relying parties.

As stated in the prior section, it is critical to perform a risk assessment and develop a threat model prior to deploying a PKI. The recommendations provided throughout this paper are not one-size-fits-all for every PKI deployment; each deployment is unique in its requirements. To assist in determining what recommendations may apply to your deployment, each recommendation has been categorized based on impact level, which (at a high level) is a measure of the impact a CA breach would have on the business it supports. The following impact levels are used to classify the recommendations:

  • High Business Impact – Customer or Partner Impacting – This classification relates to CAs that, if compromised, could impact your customers or partners, as well as have an internal impact.
  • High Business Impact – Internal Impact – This classification relates to CAs that if compromised, could impact internal operations of your company significantly. Examples include CAs that issue certificates used to protect proprietary data, or allow authentication to internal systems or networks. Many ADCS deployments, regardless of intended use, will fall into this category.
  • Moderate Business Impact – This classification relates to CAs that are not widely trusted in your environment or do not support critical business processes.

Each CA should be analyzed to determine the impact of a breach. In most cases, all CAs in a hierarchy will have the same impact level. However, there are some cases where a subordinate CA may have a lower impact level than the root or other subordinate CAs because technical constraints may prevent it from being used in more critical use cases. For a complete list of recommendations in this paper along with the recommended impact level at which to implement them, refer to Securing PKI: Appendix F: List of Recommendations by Impact Level.

Except in exceptional cases, compromise of a PKI is not the ultimate goal of an attacker. Rather, an attacker’s motivation is typically to acquire other desirable data such as trade secrets, payment card data, or other data. Compromising a PKI in an environment may be a necessary step for attackers to gain the credentials required to access the desired data. There are several compelling reasons why an attacker may attempt to compromise a PKI as part of an enterprise breach:

  • Elevation of privilege – An attacker can leverage the PKI to gain credentials that will allow them to gain full access to desired systems or potentially all systems across the target environment.
  • Persistent access – While many attacks begin with attackers using backdoors on systems to maintain access to an environment, compromising a PKI and obtaining credentials can allow attackers to use the “front door” and access the environment through legitimate means such as a Virtual Private Network (VPN) or DirectAccess (DA).
  • Impersonation – Compromising a PKI can allow an attacker to create credentials of VIP users who have access to desired data.

In many cases, compromising a PKI and obtaining fraudulent certificates allows an attacker to traverse the network using methods that look very similar to normal user activity and are difficult to detect.

PKI systems should be guarded as some of the highest security systems in an environment, so an attacker may require several steps to accomplish a compromise. In a typical breach, attackers gain a foothold into the environment by exploiting systems not current with security patches or outdated applications. For a more complete list of common attack vectors in an Active Directory® environment, refer to Best Practices for Securing Active Directory. Once the attacker gains some basic level of access within the network, the following are some of the common scenarios that result in a compromise of the PKI:

A common method of compromise is for attackers to leverage misconfigurations within the PKI to issue certificates for other users of systems for which the requesting user should not have rights to request, or certificate types that the user should not be able to request. Examples include misconfigurations in template permissions, such as overly broad enrollment permissions, or misconfigurations on the CA that allow users to request certificates with user-defined data. Misconfigurations in allowed certificate usages and constraints could also allow attackers to create subordinate CAs with arbitrary attributes.

In many cases, the CA servers are run and managed similarly to any other system in the environment. This includes the CA systems being built from the same image as other systems and includes many unnecessary applications that increase the attack surface of the CA. Operating a CA in this manner exposes it to many additional attack vectors, including attacks from other enterprise systems such as monitoring, update management, backup, inventory, etc. PKI attacks are sometimes opportunistic in the sense that an attacker may not have been planning on compromising PKI, but because they gained a credential for an account that had access to the PKI, they leverage it. Common vectors for attack in this scenario are passwords left with default build values, generic configurations of software that allow overly broad access, or excessive administrator rights on the CA.

In other cases, the CA is built using a custom “one off” configuration where adequate documentation does not exist and the configuration has not been thoroughly tested. While custom installations can lessen the attack surface when done correctly, they can also introduce misconfigurations, as standard processes are often not followed. Compromised CAs often do not adequately protect the CA keys, leaving them vulnerable to attackers either on the system or in backups.

Many PKI designs use a front end RA system to handle validating requests for certificates. While the back end CA may have good security, in some cases the RA systems are not secured in the same manner. If this is the case, attackers may be able to compromise the RA and use its credentials to issue the certificates they need to further their attack. Some examples of RA systems include smart card management software, Network Access Protection (NAP) Health Registration Authority (HRA), and Network Device Enrollment Services (NDES).

Each CA should implement its own set of practices, both logical and process-driven to ensure the identity of the subject requesting a certificate is validated. If there are deficiencies in these practices, it is possible for an attacker to use social engineering techniques to have certificates issued to them. For example, an attacker could have an employee smart card shipped to them by pretending to be a remote employee if home addresses are not validated. An attacker pretending to be a web administrator could have an SSL certificate issued on behalf of a highly sensitive payroll system to perform a man-in-the-middle attack.

Whether you are operating an existing PKI or planning to deploy a new PKI in your environment, the recommendations provided in this paper are intended to mitigate many of the common insecurities and shortcomings addressed in the previous section. Beginning with recommendations to consider during the design phase, each section will cover an aspect of PKI systems and provide recommendations for specific approaches or general guidance to consider for the threats in your environment. Not all the recommendations provided in this paper will be applicable to every environment. Consider the Determining the Level of Protection Required would have on your business through a risk assessment and implement those controls which help to mitigate the known threats. A comprehensive list of all recommendations in the paper is provided inSecuring PKI: Appendix F: List of Recommendations by Impact Level, along with the impact level at which you should apply the recommendation.

X.509 certificate definition

Leave a comment


An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate.

An X.509 certificate contains information about the identity to which a certificate is issued and the identity that issued it. Standard information in an X.509 certificate includes:

  • Version – which X.509 version applies to the certificate (which indicates what data the certificate must include)
  • Serial number – the identity creating the certificate must assign it a serial number that distinguishes it from other certificates
  • Algorithm information – the algorithm used by the issuer to sign the certificate
  • Issuer distinguished name – the name of the entity issuing the certificate (usually acertificate authority)
  • Validity period of the certificate – start/end date and time
  • Subject distinguished name – the name of the identity the certificate is issued to
  • Subject public key information – the public key associated with the identity
  • Extensions (optional)

Many of the certificates that people refer to as Secure Sockets Layer (SSL) certificates are in fact X.509 certificates.

The first X.509 certificates were issued in 1988 as part of the International Telecommunications Union’s Telecommunication Standardization Sector (ITU-T) and theX.500 Directory Services Standard. In 1993, version 2 added two fields to support directory access control. Version 3 was released in 1996 and defines the formatting used for certificate extensions.

PKI security for embedded systems – Public Key Infrastructure (PKI) isn’t just for enterprise applications – a Machine-to-Machine (M2M) authentication strategy based on PKI can form the backbone of a secure embedded system.

Leave a comment


Embedded systems are now pervasively deployed in diverse large markets: industrial, medical, telecom, home appliance, consumer, automotive, and others. As Internet adoption proliferates, more embedded devices and applications are being connected to networks to take advantage of the extraordinary benefits of the Web. Some experts predict that the number of Web-connected devices will soon exceed the number of human users and grow to far higher levels.

The success of Internet-connected consumer products and applications results from the remarkable progress vendors have made in providing ease of use and, thus removing major barriers to widespread usage by people of all ages across the globe. Billions of users now confidently make transactions online with public and private companies, banks, and health organizations. They purchase books, cars, stocks, retirement plans, insurance policies, and many other things. Consumers and businesses exchange products of small and large dollar values over the Internet.

Numerous security mechanisms, technologies, and policies have emerged to make such transactions possible and protect the trading parties. In addition, enterprises, banks, e-commerce companies, and the computing industry (hardware and software) have invested serious amounts of money to educate, enable, and monitor such transactions and respond quickly to inquiries. Enterprise IT staffs, bank payment networks, and e-commerce system providers constantly supervise their networks to ensure that transactions are performed legitimately and that risks are contained early on when they arise.

But what about the millions of Web-connected devices – how secure will they be?

Strong security needed in the embedded Internet

Authentication technologies (multifactor) and password-management processes are commonly available to all users including consumers and employees of an enterprise. Public Key Infrastructure (PKI) technology is widely deployed and effectively used on the Internet to ensure that every user is indeed interacting with a legitimate online service such as a bank, e-commerce company, or government agency.

Given the growing number of Internet-connected embedded devices, an important question arises: How will these devices provide a reliable and safe service when they are left unsupervised and connected to the Web? Unless devices incorporate strong security capabilities, they are highly exposed and vulnerable to misuse and hacks. For example, how can a remote machine reliably perform a command if it can’t verify with high certainty that it has received that command from a legitimate host? Would a weak authentication approach be acceptable, knowing that millions of deployed devices can interact with the public infrastructure or with equipment in private homes? Given the risk, what level of protection is appropriate and adequate?

This is a real problem; one that is being identified by major initiatives including the , cyber security, health care automation and other areas requiring strong protection. This situation now presents a technology opportunity: Machine-to-Machine () authentication.

Challenges of PKI adoption for embedded devices

Experts in enterprise IT, e-commerce, banking, and the Internet Engineering Task Force know that PKI technology provides the strongest and most effective authentication solution available today. However, the huge global embedded devices market has evolved in an isolated manner and for the most part has not yet adopted this proven technology. The reasons for the delay include:

·    Very tight constraints (limited ) on the : In most applications, the main MCU does not have the resources needed to perform PKI computations. Many embedded system designs still use outdated security solutions built with memory chips, which provide a weak level of security unsuitable for Web connectivity.

·    Cost pressure and lack of skills: PKI is perceived as an expensive technology that is difficult to implement in the design and deployment phases and requires an expertise not commonly available among embedded system designers. Thus, a standard off-the-shelf memory chip is assumed to be good enough and is easy to include in a design.

·    Proprietary environment not often connected to the external world: The risk of hacks is underestimated, and/or the proprietary security scheme is believed to be sufficiently robust to successfully withstand attacks.

Overcoming barriers to acceptance

The computing technology for embedded systems is changing rapidly. More higher-performance microcontrollers are available today at attractive cost points. Furthermore, a generation of secure MCUs can be integrated easily into designs, thereby providing an unparalleled level of authentication security without impacting the application performance of the main MCU.

Three major Renesas innovations are bringing PKI-based security to the community of embedded system designers.

First, the Board ID-based M2M authentication chip delivers a very high level of security using the same security technologies rigorously tested and proven in the billions of smart card ICs produced to date. This chip can connect to virtually any processor (MCU or MPU) using a standard serial communication interface (I2C). The chip incorporates multiple electrical and mechanical safeguards to make it tamperproof and is produced at Renesas Electronics’ manufacturing facilities, which meet the strict security standards of the smart card industry and are approved by bank and government ID issuing authorities.

Second, a complete suite of security service software and firmware provides an M2M authentication solution that takes a comprehensive approach to risk minimization. It includes a suite of hardware and software components and partner services that combine to offer a complete service to embedded system designers.

Finally, PKI services are available from a distribution partner for OEMs. A major strength of PKI that is also an element of complexity is the necessity to generate unique keys and a certificate (X509) for each security chip and thus for each device. Until recently, this process was economically viable only for large customers in the enterprise, e-commerce, and banking markets. Renesas Electronics America and Avnet have partnered in a chain of trust, shown in Figure 1, to change this situation, making it more viable to other firms by delivering an affordable, secure, easy-to-use/deploy PKI solution. This robust security solution complies with industry standards and can be made available to companies of all sizes that need protection against misuse.

Figure 1: Through the Renesas Electronics America and Avnet chain of trust, companies of all sizes can access an affordable, robust PKI solution.

This partnership provides the critical service components necessary for implementing complete security solutions, as illustrated in Figure 2:

·    A root-of-trust Certificate Authority

·    A sub-Certificate Authority (optional)

·    A system for generating unique certificates and private keys for each Board ID chip

·    A programming service provider that can securely insert the certificate and key pairs in each chip

Figure 2: The combination of technologies and services resulting from the Renesas Electronics America and Avnet partnership provides the critical elements needed for implementing complete security systems.

(Click graphic to zoom by 1.7x)

Security for any embedded device

This combination of innovations in the product and business and service models enables the Renesas Board ID security solution to eliminate or significantly reduce previous barriers to the adoption of PKI technology.

A company does not have to be an IBM, General Electric, or Google to successfully apply this security technology. Whether shipping 20,000 products or hundreds of thousands of them, companies can now innovate and design Web-connected embedded devices that incorporate state-of-the-art PKI security technology. This capability will facilitate the development of products that can become part of the ever-growing embedded Internet for the smart grid or other ambitious programs that leverage the Web.

Note: This document does not cover the details of the cryptography and security mechanisms. More technical details about PKI technology are available at theRenesas Electronics website and through various public sources such as theNational Institute of Standards and Technology, Federal Information Processing Standards, and others.

Nadaradjane Ramatchandirane is the senior business development manager of the Consumer and Industrial Business Unit at Renesas Electronics America responsible for managing business development in the security space. He joined Renesas Technology America in 2007 (now Renesas Electronics America), and prior to that held executive positions at Schlumberger/Gemalto, ActivIdentity, Hypercom, and Bitfone.

Renesas Electronics America Inc.