x.509 Certificate Requirementscmsresources.windowsphone.com/.../downloads/Windo… · Web viewConfiguration service providers can be used to provision the phone with settings specific

Windows Phone 8 Partner ServicesCertificate Provisioning Request

Request date [DD-MMM-YYYY]

OEM name [OEM Name]

Unique certificate name [OEM Name]-[Unique Certificate Name]

Certificate description [For example: build team located in Chicago]

Certificate owner name [Last Name, First Name]

Certificate owner email address [[email protected]]

1. X.509 CERTIFICATE REQUIREMENTS

This certificate is used to authenticate submissions made to Microsoft using the Ingestion Client. It is not used to sign any files, packages or payload. When you install the Ingestion Client, you will provide the path to a .pfx file for this certificate, and the installer will import the certificate into the certificate store, and write the thumbprint information into the configuration file at: % ProgramFiles(x86)%\Microsoft\WP Ingestion Client\Modules\Microsoft.Phone.PartnerServices.Client\Microsoft.Phone.PartnerServices.Client.dll.config. (See the Ingestion Client documentation for more details). The Ingestion Client will then utilize the certificate from the store to authenticate submissions and requests to the Microsoft services.

In order to ensure secure communications, the certificate has these requirements.

Signature Encrypted at a minimum with SHA1 algorithm (SHA-256 preferred) Certificate expires 3 years from the submission date, or earlier Certificate is self-signed or has a valid commercial certification authority as its root.

Note: For more information regarding valid certificates, please see the “Obtaining an X.509 Certificate” section of the Windows Azure Access Control Services documentation. This also includes an example command line using makecert.exe to generate a self-signed certificate. http://msdn.microsoft.com/en-us/library/gg185932.aspx

Please do not follow the instructions on that site to export the certificate, please follow the instructions in this document.

Microsoft Confidential: Distributed Only to Partners Under Nondisclosure

http://msdn.microsoft.com/en-us/library/gg185932.aspx

Further documentation on makecert.exe can be also be found on MSDN.

2. DELIVERING THE CERTIFICATE TO MICROSOFT

1. CREATE THE CERTIFICATE FILE TO SEND TO MICROSOFT

Important! Only send us the public key in a .cer file. If you send Microsoft a certificate file that includes the Private key, we will reject it and you will need to create a new certificate and only send us the public key. You can find more instructions on how to create or export only the public key in documentation for Managing Certificates with the Microsoft Management Console. It is recommended to use the Certificate Export Wizard. For example:

o Open Microsoft Management Console and add the Certificates snap in(or run certmgr.msc from a command prompt)

o Select the certificate to use for authentication.o Export the certificate using the Certificate Export Wizard, and select (do not export private key,

DER encoded binary X.509 (.cer))

o You will need a .pfx file with this certificate to install the Ingestion Client. If you don’t already have a .pfx file for the certificate, export the certificate again. Using the Certificate Export Wizard, and select (export private key, Personal Information Exchange – PKCS (.PFX) + Include all certificates in the cert path if possible.


http://technet.microsoft.com/en-us/library/cc771377.aspx

2. DELIVERING THE CERTIFICATE FILE TO MICROSOFT

Rename the .cer file as a .txt file. Place the completed form and .txt file in a .zip file Attach this zip file to your onboarding request e-mail.

SECURE MANAGEMENT OF CERTIFICATES

The OEM is required to keep their private keys secure. Microsoft does not specify how to do this. We expect these criteria will be met:

The OEM owns the certificate and is responsible for its security. The private key of the certificate represents the identity of the OEM. The OEM must manage it using industry best practices and protect it as an important and confidential asset. The OEM may provision multiple certificates, but they are encouraged to keep the number of certificates small. This ensures that the OEM will not be burdened by a frequent time-based revocation policy for certificates, and it will reduce operational overhead. Typically, an OEM geographic site is expected to have one or two certificates.

By default, the same certificate is provisioned for production and pre-production environments unless specifically requested otherwise by the OEM.

The OEM must notify Microsoft when a certificate is revoked, expires, or for any other reason that would require Microsoft to de-provision the certificate and disable its access.

Only people who need access to the private key should have access. The OEM should protect the private key as well as you would their own corporate assets.

Following is one approach you could use. This does not guarantee the certificates are secure; you maintain the responsibility for keeping keys secure and informing Microsoft if your keys become compromised so appropriate action can be taken.


Code-Signing Infrastructure Guidance

January 2014

The Code-Signing Infrastructure Guidance document describes features that are subject to change, and should therefore be considered preliminary

Microsoft CorporationRev. 9


Proprietary Notice

This document is provided "as-is." Information and views expressed in this document, including URL and other Internet website references, may change without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. This document is confidential and proprietary to Microsoft. It is disclosed and can be used only pursuant to a non-disclosure agreement.

CONFIDENTIAL. Distribution only to partners under nondisclosure. Microsoft makes no warranties, express or implied.

©2014 Microsoft Corporation. All rights reserved. Microsoft, Active Directory, Authenticode, MSDN, Windows, and Windows Server are trademarks of the Microsoft group of companies. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.


ContentsCode-Signing Infrastructure Guidance.........................................................................................................................4

Test Signing vs. Production Signing..................................................................................................................6

Code Signing During Software Development...................................................................................................7

What Test Signing Is.....................................................................................................................................7

Test Signing by Individual Developers..........................................................................................................8

Integrating Test Signing into the Build Environment....................................................................................9

Configuring a Test Computer or Environment..............................................................................................9

Test-Signing Operations.............................................................................................................................11

Code-Signing Service Best Practices...............................................................................................................11

Cryptographic Key Protection.....................................................................................................................11

Signing Environment..................................................................................................................................13

Code-Signing Submission and Approval Process........................................................................................13

Auditing Practices.......................................................................................................................................14

Test Signing................................................................................................................................................14

Release Signing...........................................................................................................................................15

Certificate Acquisition from a Commercial CA............................................................................................15

Automation................................................................................................................................................15

Separation of Duties...................................................................................................................................16

Code-Signing Service Example Topologies.....................................................................................................16

Example Production Signing Process..........................................................................................................17

Production Signing Workflow.................................................................................................................21

Operations..............................................................................................................................................22

Backup of Private Keys...........................................................................................................................23

Disaster Planning for Private Keys..........................................................................................................23

Destruction of Private Keys Used for Production Signing.......................................................................24

Deployment View of Code Signing Infrastructure..................................................................................24

Sample Bill of Materials for Code Signing Lab........................................................................................25

Engineering Unlock....................................................................................................................................25

Life Cycle Management for Image Unlock Certificates...........................................................................26

Engineering Unlock Workflow................................................................................................................27

Engineering Unlock Operations..............................................................................................................28

Certificate Management Tools.......................................................................................................................29


Configuring System Certificates Stores.......................................................................................................30

Code-Signing Resources.................................................................................................................................31

Code-Signing Basics........................................................................................................................................33

Digital Certificates......................................................................................................................................35

Identity and Policy......................................................................................................................................35

Certificates and Keys..................................................................................................................................35

Roles Within the Code-Signing Ecosystem.................................................................................................36


Code-Signing Infrastructure GuidanceProtecting personal and corporate data is a top concern for consumers and OEMs around the world. Software with digital signatures based on certificates and keys is an important method to ensure the robustness and integrity of computer systems. A digital signature allows a Windows Phone to detect if a package has been tampered with since it was signed.

The cryptographic keys that are the core of the code-signing process must be well protected and treated with the same care as a company’s most valuable assets. These keys represent a company’s identity. Software that is signed with these keys bears a valid digital signature that can be traced to the company. If a key is stolen, the thief could, for example, use it to fraudulently sign malicious code and deliver an application that contains a Trojan horse or virus that appears to originate from a legitimate publisher.

This guide describes the best practices for implementing code-signing services for testing and production. These recommendations are general principles to guide the decision-making of organizations that want to implement a code-signing infrastructure. Following the guidance will help prevent problems such as compromising the private key, signing prerelease software with a release signing key, or allowing malicious software to be signed.

Conforming to the best practices that are described here does not necessarily require a large expenditure or time commitment. Organizations might find it useful to perform a formal security analysis to understand what measures are appropriate to protect their identity and reputation. The controls put in place to secure a code-signing infrastructure can be tailored to the circumstances of the code signer and the value of the private signing key. There is no one-size-fits-all solution; each organization must determine the right balance between security, cost, and impact on development processes.

Although proper management of certificates is critical, it is just one piece of a comprehensive approach to security. For additional important security considerations, see Security Overview for Windows Phone in the Windows Phone Partner Documentation.

Creating a Code-Signing InfrastructureTo help create a more secure phone, the OEM must track each use of their certificates and make sure that systems are in place to manage the creation and storage of all certificates.

Windows Phone Certificate UseThe following are the primary areas in the OS that use certificates.


Certificate use Information

Certificates installed by the OEM provide a credential to verify the identity of a phone, authenticate a service, or encrypt files or connections. Windows Phone has a set of preinstalled root certificates that are included in the phone’s certificate store. It is also possible to add intermediate, root, and self-signed certificates to the phone by using provisioning.

Provisioning a Phone with Network-specific Settings

Microsoft provides to the general public a list of the root certificates that are shipped on the phone. "Windows Phone 7 Root Certificates" is available on MSDN at Windows Phone 7 Guides for IT Professionals.

Configuration service providers can be used to provision the phone with settings specific to a given mobile operator’s network. This provisioning information can be included in the phone OS by using a .provxml or .xml file, or it can be sent over the air. For more information about standard configuration operations that can be performed, see the Provisioning Guide for Windows Phone.

The CertificateStore Configuration Service Provider allows you to add secure sockets layer (SSL) and intermediate, self-signed certificates.

A full flash update file must be cryptographically signed before it can be deployed to a phone. This step is required to prevent tampering and malicious attacks. Windows Phone accepts only signed images during full flash update.

Signing the Full Flash Update File

Before shipping the phone, the default vendor BSP certificate must be replaced with production certificates that will be used to verify OEM updates.

Production Certificates for Updates

The Windows Phone boot loader (BLDR) update loader can be used to update the modem. These modem updates must be signed by the OEM by pointing the package to the DefaultOemCerts.proj file.

none

The OEM has the ability to implement flashing technologies in the OEM system boot loader (OSBL). If the OEM has done this, they must work with Qualcomm to secure the OSBL and sign modem updates.

Contact Qualcomm for information and code samples that must be used to secure the OSBL.

Any other certificates that are included on the phone by the OEM should also be managed by using a rigorous process as described in this guide.

Creating a Code-Signing InfrastructureThe following are the principle tasks for implementing a robust code-signing infrastructure.


Security Note:

http://go.microsoft.com/fwlink/?LinkId=212390


Task Information

Become familiar with the basics of certificates, keys, and code signing. Code-Signing Basics

Code-Signing Resources

Become familiar with certificate management tools. Certificate Management Tools

Code-Signing Resources

Create a secure infrastructure for the storage and management of certificates.

Code-Signing Service Best Practices

Understand the need for both test signing and production signing. Test Signing vs. Production Signing

Create a code signing topology for test signing that is used during software development.

Code Signing During Software Development

Create a code-signing topology for production signing. Example Production Signing Process

Create a code-signing topology for unlocking engineering phones. Engineering Unlock

Test Signing vs. Production SigningMicrosoft recommends that commercial software publishers establish a separate test code-signing infrastructure to test-sign prerelease builds of their software. Test certificates must chain to a completely different root certificate than the root certificate that is used to sign publicly released products. This precaution helps ensure that test certificates are trusted only within the intended test environment.

Using test certificates during development has several advantages:

Code signing during testing provides more authentic test coverage by exercising signing-related code paths.

Test signing is much more efficient than release signing for daily use during development. In particular, members of the development team can have much greater access to test certificates and private keys than they do to release certificates and private keys.

Using test certificates during testing ensures that if prerelease code is accidentally released to the public, it is not signed with the organization’s production certificate.

Test certificates can be deployed broadly to an organization's developers or contractors to identify the creator of software. This provides accountability in the development process and a measure of software integrity.

It is recommended to reserve production certificates that are issued by commercial CAs for signing only public beta and final releases of the OS images and updates. If the best practices for managing keys—discussed elsewhere in this documentation—are followed, the private keys that are used for release signing will be behind a security


boundary. The private keys will be accessible to only a few trusted individuals and will require an approval process before the private keys can be used to sign code.

Test certificates, on the other hand, are valid only in a test environment, so access can be granted more broadly. Using test certificates to sign code does not require the same sort of controlled process as production signing. For more information on test-signing see Code Signing During Software Development.

If code is signed automatically as part of a build process, it is highly recommended that any code that is submitted to that build process be strongly authenticated.

Code Signing During Software DevelopmentWhen preparing preliminary Windows Phone OS images, there is a need to verify functionality before the image is ready to be publicly released. It is critical that the private keys that are used to test-sign prerelease builds be different from the keys that are used to release-sign the final production image.

This section discusses what test signing is and describes how developers and testers can test-sign prerelease builds. This process ensures that the software behaves as expected on a test computer or in a test environment before signing the application for public release. This section also includes discussions of several scenarios for test signing during the development cycle:

What Test Signing Is Test Signing by Individual Developers Integrating Test Signing into the Build Environment Configuring a Test Computer or Environment Test-Signing Operations

What Test Signing IsTest signing is the act of digitally signing an application with a private key and corresponding code-signing certificate that is trusted only within the confines of a test environment. Test signing ensures that an application functions correctly during installation and run time before it is signed with the publisher's release code-signing certificate for public distribution. The procedures are essentially similar to those that are used to release-sign an application. However, there a number of reasons for having a separate test-signing process and reserving release signing only for publicly released builds such as public betas and final releases.

It is much easier for organizations to recover from a compromised test certificate than from a compromised release certificate because test certificates are trusted only within the confines of a test environment.

Using test certificates during testing ensures that accidentally leaked prerelease applications are not signed with the organization’s release certificate.

Using the release certificate’s private key exclusively for release signing minimizes the chances of accidentally signing code that should not be signed.

Development teams can have much greater access to test certificates than release certificates. Easier access to test-signing keys means greater efficiency for the development team.


Note:

Test certificates are normally created in-house. In the event of a problem, such as a compromised test certificate, organizations can simply reset the test environment and issue a new test certificate. This is significantly easier than issuing a security bulletin to customers and publicly revoking a release certificate.

A test-signing environment can be implemented very cost effectively by using free utilities or features that are built into Windows. Tasks such as issuing test certificates, configuring test computers, or even test signing builds can be automated, depending on an organization’s level of investment.

Test Signing by Individual DevelopersDuring the earlier phases of the development cycle, it is useful for developers to test-sign their binaries by using their own test-signing certificates. There are two primary ways to generate such test-signing certificates:

Developers can generate their own self-signed certificates. Certificates can be issued from a test-signing CA.

For either option, test-signing certificates should be clearly identified as appropriate only for testing purposes. For example, the word "test" could be included in the certificate subject name, and additional legal disclaimers could also be included in the certificate

Self-Signed Test CertificatesDevelopers can use the MakeCert tool to generate self-signed test certificates for signing their code. In this context, a self-signed certificate is a certificate that is signed by the certificate's own private key, which is not issued by a CA.

There are three advantages of self-signed certificates:

Self-signed certificates require no overhead or infrastructure. The necessary tool is available free as part of the Windows SDK. The developer can operate independently of any infrastructure components in the development

environment.

The main drawback of using self-signed certifications is that the developer must acquire and learn to use MakeCert. Additionally, developers must configure their test computers to recognize their self-signed certificates as “trusted” before the test computers will be useful for testing test-signed applications. This can be done manually or with scripting. The most convenient options for configuring test computers are the Microsoft Management Console (MMC) Certificates snap-in (see Configuring System Certificates Stores) and the CertMgr command line tool (see Certificate Management Tools). For more information on using self-signed certificates, see Configuring a Test Computer or Environment.

In theory, it is possible to use Group Policy to configure a self-signed certificate on multiple computers. However:

Using Group Policy to configure multiple certificates can create manageability problems. Group Policy is the only centralized way to revoke self-signed certificates. This could be a problem if

a computer is disconnected from the network for an extended period.

Test Certificates Issued by a Certification AuthorityAnother option for issuing test certificates to developers is to have a domain administrator or network manager issue test certificates through a centrally managed CA, such as a Microsoft Certificate Server.


Deploying Microsoft Certificate Server is most effective in a domain environment with Active Directory. This environment is not required to deploy a Microsoft Certificate Server, but a properly configured domain, CA, and Active Directory largely eliminate certificate management tasks for developers who only need to sign prerelease applications with individual test certificates.

CA administrators have several models that they can use to issue test certificates:

The CA administrator automatically issues certificates to all members of a specified domain, typically developers and testers.

CA clients make certificate enrollment requests. There are two ways to handle the approval process: The CA administrator designates a specific individual to manually approve each request. The CA automatically evaluates each request based on access control lists (ACLs), previously

configured by the CA administrator. The CA administrator designates specific individuals to make certificate enrollment requests on behalf

of the members of the organization.

In addition to centralizing the process, a CA makes other aspects of certificate management simpler, including expiration, revocation, and reissuance.

Test computers can be configured through Active Directory or with Group Policy. If these techniques are not desirable, other options include manual configuration with the MMC snap-in or command-line scripts that use CertMgr. For more information, see Configuring a Test Computer or Environment.

Integrating Test Signing into the Build EnvironmentIntegrating test signing into an automated build process can save the development team considerable time and effort. For the purposes of this documentation:

A build process is a centralized, automated process that compiles both release and prerelease software from source files that are stored in a source control system.

The source control system ensures that only approved source files are compiled, tracks submissions from individual developers, and allows code changes to be rolled backward or forward.

Developers and testers typically develop against or test with the most recent build. The productivity of an entire software team may depend on getting the latest build as quickly as possible.

Given these characteristics, it makes sense for many development teams to integrate test signing into their build process:

Build integration saves time because the signing is part of an automatic, centralized process. Developers do not have to concern themselves with the mechanics of code signing.

Build integration can be very helpful for signing software packages that have complex signing requirements.

Here are some things to remember when integrating test signing into a build procedure:

Test signing a build can be performed with a self-signed certificate or a CA-issued certificate. The test-signing certificate must be configured to be trusted on each computer on which binaries are

tested. This can make a CA-issued certificate a more practical choice for larger environments. For information on configuring test computers, see Configuring a Test Computer or Environment.


Test signing must occur after the binaries are in their final form. Procedures such as rebasing or localizing a signed file invalidate the signature.

In a well-architected build process, the only difference between test and release signing is whether the code is signed locally with a test certificate or submitted to a code-signing service for release signing.

If many files must be submitted to a code-signing service, consider using signed catalog files. It requires less network bandwidth to transfer a single catalog to the code-signing service, and the signing operation requires less time for a single file.

Automatically release signing the output of a build process requires a carefully considered security model. For additional security requirements, see Code-Signing Service Best Practices.

Configuring a Test Computer or EnvironmentTest computers must be configured to verify test-signed applications by adding the test root certificate and test certificate to the appropriate system certificate stores. A system certificate store is a logical data store that can be configured with an MMC snap-in, CertMgr, Group Policy, or certificate auto-enrollment. For more information on certificate stores, see the MSDN document Certificate Revocation and Status Checking.

When adding a certificate to a test computer's certificate stores, do not export the private key from the computer that handles the signing process. Exporting a private key compromises its security, and the private key is not necessary for signature verification.

The remainder of this section discusses the different security stores that may have to be configured, depending on the testing scenario.

Trusted Root Certification AuthoritiesThe Trusted Root Certification Authorities certificate store contains the root certificates of all CAs that Windows trusts. For a Windows test computer to recognize a test signature as valid, the Trusted Root Certification Authorities certificate store must contain the test root certificate of the CA that issued the code-signing certificate in the signature.

Many commonly used commercial CA root certificates are in the Trusted Root Certification Authorities certificate store by default. However, if an application is signed with a self-signed certificate, that certificate must be added to the Trusted Root Certification Authorities certificate store. Otherwise, Windows will not successfully verify the test signature.

Trusted PublisherThe Trusted Publishers certificate store is different from the Trusted Root Certification Authorities certificate store in that only end-entity certificates can be trusted. In other words, adding a test CA root certificate to the Trusted Publishers certificate store does not configure as trusted all certificates that this CA issued. Each certificate must be added separately.

Machine and User Certificate StoresTwo types of system certificate stores are relevant to configuring a test computer: user certificate stores and machine certificate stores. There is one set of machine certificate stores per computer and one set of user certificate stores per user account. Note that all user certificate stores inherit the contents of the machine-level


Important:


certificate stores. If a certificate is added to the Trusted Root Certification Authorities machine certificate store, all Trusted Root Certification Authorities user stores will also contain the certificate.

The required level of privilege to configure a certificate store depends on the type of store. Users with administrator privileges can configure the machine store and their own user stores. Users with lower privileges can configure only their own user stores.

Test Computers vs. Test EnvironmentsThe best way to configure a test computer depends on its broader environment:

A single test computer is most easily configured by double-clicking the certificate's .cer file, launching the MMC Certificates snap-in, or running CertMgr from the command line.

A larger test network that is not joined to a domain can be configured by creating client side scripts that call CertMgr.

A larger test network that is joined to a domain can use either of the preceding mechanisms. However, it is recommended to configure such computers with either Group Policy, or Microsoft Certificate Server with Active Directory. For further information, see Certificate Acquisition from a Commercial CA.

Test-Signing OperationsTest signing can be performed by individual developers or by a centralized build process. To set up a test-signing operation:

1. Acquire a test code-signing certificate with a private key.2. Configure the code-signing certificate:

If the certificate is issued by a CA, the CA must be configured in either the user or machine Trusted Root Certification Authorities certificate store. This ensures that the tool that is used for signing will recognize the certificate's validity.

If the test certificate is self-signed, it must be located in the Trusted Root Certification Authorities certificate store.

3. Acquire and become familiar with the operation of the signing tools.

Code-Signing Service Best PracticesAs discussed in the introduction, the cryptographic keys that are the core of the code-signing process must be well protected and treated with the same care as a company’s most valuable assets.

It is therefore essential for partners to implement policies defining:

How private keys are to be protected. Who approves code-signing operations. How to ensure that only high-quality, approved code is signed and released to the intended customer.

These policies should be in place before acquiring a code-signing certificate.

This section describes the best practices for implementing code-signing services for testing and production. These recommendations are general principles to guide the decision-making of organizations that want to implement a code-signing infrastructure.


Cryptographic Key ProtectionMicrosoft recommends that software publishers store cryptographic keys for code signing in a secure tamper-proof hardware device. Keys that are stored in software are more susceptible to compromise than keys that are stored in hardware. For example, if a software key is leaked, the key or file that contains the key is typically copied, making it difficult to detect the breach. Keys that are stored on hardware are less vulnerable to undetected compromise.

Three types of hardware devices are typically used to protect code-signing keys:

Smart cards. Smart card–type devices such as Universal Serial Bus (USB) tokens. The best practices discussed

here for smart cards also apply to smart card–type devices. Hardware security modules (HSMs).

HSMs are dedicated hardware devices that store and protect cryptographic keys. They are typically used by medium to large organizations with substantial code-signing requirements. Although HSMs offer more features than smart cards, smart cards and smart card–type devices might be sufficient for smaller organizations with fewer code-signing requirements.

Organizations should consider the criteria in the following table when evaluating smart cards against HSMs.

Key Protection Evaluation Criteria

Criteria Smart card Hardware security module

Certification: FIPS 140-2 Level 3 Generally, no

Yes

Key generation in hardware Maybe Yes

Key backup No Yes

Multifactor authentication No Maybe

Speed Slower Faster

Separation of roles No Yes

Automation No Yes

Destruction Yes Yes

The following list explains the terms and issues that are summarized in the preceding table:

Certification. Federal Information Processing Standard (FIPS) 140-2 is a U.S. Government standard that provides criteria for evaluating cryptographic modules. As a best practice, Microsoft recommends


that vendors use FIPS 140-2 Level 3 certified products. Industrial HSMs normally have this certification, but smart card devices usually do not.

Key generation. When keys are generated, they should never be exposed as plain text outside the hardware device. Industrial HSMs provide key generation in the hardware. Smart card implementations might support this feature.

Key backup. Keys should be backed up for disaster-recovery purposes and to mitigate the risk of a hardware failure. It is important that keys not be exposed in plain text outside the HSM during backup operations. Industrial HSMs support secure key backup from one FIPS 140-2 Level 3 certified device to another. If the keys are not backed up and the hardware device fails, new keys must be issued.

Multifactor authentication. Organizations should require more than one approver for a code-signing operation. This is referred to as "k of n," where a specific number of authorizations must be present to perform any cryptographic operations. For example, three trusted individuals out of seven must be present to digitally sign software.

Some HSMs support multifactor authentication. A multiple-approver requirement can be met with a smart card, but it must be accomplished in other ways. For example, a smart card could be stored in a safe that requires multiple keys, or one officer could know the safe's combination while another knows the smart card's personal identification number (PIN).

Speed. Smart cards generally perform cryptographic operations more slowly than industrial HSMs. HSMs contain dedicated cryptographic accelerators, which makes them better suited to high-throughput environments. Any organization that requires more than 100 signings per week should consider using an HSM.

Separation of duties. Administrative and operational roles should be segregated to avoid relying upon a single individual or team.

Automation. HSMs support automated signing. With smart cards, someone must manually enter a PIN for each signing operation. High-throughput or time-sensitive environments that require automated signing should deploy an HSM.

Destruction. HSMs support the complete key life cycle including key destruction. If a private key becomes invalid for any reason, it is important that the key be destroyed. This can be accomplished by overwriting the key on the HSM or smart card or by physically destroying the device.

Signing EnvironmentThe signing environment must be physically secure. Otherwise, there is no way to prevent smart cards or HSMs from being lost or used to sign inappropriate content. The value and availability requirements of the code-signing infrastructure dictate the physical and logical barriers that must be implemented. For example, for a low-throughput infrastructure it may be sufficient to keep an HSM in a locked room that is accessible to only a limited set of individuals. In contrast, a high-throughput production infrastructure may require a high-security data center.

This guide does not attempt to provide a comprehensive description of how to physically secure a code-signing environment. In general, Microsoft recommends that software publishers apply the principles of defense-in-depth by using multiple security techniques for different layers of their code-signing system. Organizations should consider the following physical security best practices:

Access controls such as locks, keycards, or biometrics to restrict access to the code-signing infrastructure

Restricted physical access to HSMs or smart cards Security cameras


Onsite security guards Visitor logging A tools-resistant server safe for online code-signing servers Logical and physical segregation of the code-signing infrastructure from the production network Periodic audits of the code-signing infrastructure to ensure compliance with documented practices

and design

For non-networked signing services, the signing computer or smart card should be kept offline in a tool-resistant safe when it is not in use. The following procedures are highly recommended for networked code-signing systems:

Keep the signing service behind a firewall or on a separate network. Consider Microsoft Internet Security and Acceleration Server or Server and Domain Isolation with IPsec.

Deploy network authentication and integrity protocols as part of the submission and approval process. Password authentication is generally not recommended. Instead, consider certificate-based authentication that uses certificates that are issued from an internal CA or domain authentication that uses Kerberos. IPsec with mutual authentication is also a viable option.

Consider using a separate drop-off-and-pick-up server as an intermediary between the corporate and signing service networks.

Because viruses can compromise the security of the OS and allow penetration of the network, practice proper computing hygiene, such as the deployment of workstation virus-scanning software.

Consider deploying network intrusion-detection systems to detect network-based hacking attempts.

Code-Signing Submission and Approval ProcessMicrosoft recommends implementing a code-signing submission and approval process to prevent the signing of unapproved or malicious code. At a minimum, the approval process should consist of three roles:

Submitter. The submitter is typically a developer. Approvers. The approvers should understand software development but also be somewhat

independent of the submitter to increase objectivity during the approval process. Requiring multiple approvers reduces the chance of accidentally signing software and mitigates the risk of a single employee signing inappropriate content. Face-to-face meetings to review code for approval are also encouraged.

Signers. The individuals who actually sign should be independent of the development and approval process. For example, an operations team could be responsible for the actual code signing.

The approval and submission process itself should be protected against compromise. Organizations should consider the following measures to ensure that submissions and approvals are genuine:

If the service is not networked, consider face-to-face submissions between trusted individuals. For networked approval, consider:

Digitally signed email from trusted individuals. Signoff through authenticated web forms.

For networked code submission, consider: Authenticated network access for code submission. Digital signatures for code submission.


Auditing PracticesMicrosoft recommends that all code-signing activities be logged for auditing purposes. In a small organization, auditing could be handled with an electronic log or physical log book that is stored in a secure location. A medium-to-large organization might record every transaction in a code-signing database. The auditing process should record data such as the name of the file, the name of the submitter, the name of the approver, the hash of the file, and the file before and after signing. This data ensures that code-signing activity can be examined and individuals can be held accountable if unintended or malicious code is signed.

If an audit server is used, it is important to ensure that the audit server is hardened. Microsoft Baseline Security Analyzer (MBSA) is a free tool that helps organizations detect common security misconfigurations, such as unnecessary active services, and identify missing security updates. Run MBSA periodically as part of regular security procedures.

Test SigningMicrosoft recommends that organizations use separate processes for signing prerelease and production code (test signing versus release signing). The use of test signing has several advantages:

Test signing limits the possibility that prerelease code could be signed with the organization’s production keys.

Test-signing keys are not valid outside the test environment, so they require less stringent security policies.

Test-signing keys are less valuable than production-signing keys, so they can be distributed more freely to members of a software development team. For example, a developer can be granted access to an individual test key, reducing the required time for seeking approval.

Access to the release code-signing infrastructure can be far more controlled than for test signing because the release keys are required less frequently.

Test-signing keys and certificates can be generated in-house with freely available tools.

For further information on test signing, see Code Signing During Software Development.

Release SigningMicrosoft strongly recommends that all publicly released code be signed with a certificate from a CA that is present in the trusted CA root store. This recommendation includes public betas as well as final releases. Software for internal use can be signed by a certificate that is issued by either a commercial CA or an internal CA that the organization manages. Major milestones might also be release signed to ensure that the release-signing process is functioning properly. However, such internal submissions should be confined to the organization and protected from public release.

Certificate Acquisition from a Commercial CAWhen obtaining a certificate from a commercial CA to sign publicly released code, the following key-generation best practices should be followed:

A minimum of two highly trusted individuals should witness the request to the CA for a certificate and the creation of the key.

The keys should be generated in hardware on an HSM. After creation, the keys should be securely backed up and stored in a secure offsite location.


For more information, see "Key Backup" under Cryptographic Key Protection.

RevocationIf a private signing key is compromised, the publisher must contact the issuing CA and have the certificate revoked. Revocation invalidates the certificate and adds it to the certificate revocation list (CRL). If signatures are time stamped, those files that were signed before the certificate was revoked still have valid signatures. Otherwise, revocation invalidates all files that are signed by using the revoked certificate. Note that revoked certificates should remain in the CRL because time-stamped signatures that were created with certificates that were later revoked can remain valid indefinitely.

If legitimately signed applications are signed and time stamped after the malware is signed and time stamped, revoking the compromised certificate invalidates the signatures on the legitimately signed applications in addition to the malware.

The most effective way to limit the risk of a compromised key is to implement good security policies and procedures.

AutomationAutomation, in the context of this documentation, means a process for automatically approving and signing code that is submitted to a code-signing service without requiring manual approval. This approach can shorten the turnaround time for builds and increase the available time for development. However, automation extends the trust boundary from the code-signing service to the build process itself. Organizations that use automation should implement a layered security approach to ensure that only approved code can be submitted to the build process and subsequently signed.

Some additional recommendations for a robust automation process include the following:

Authenticate and audit the process for approving code that is submitted to the build process. Authenticate submissions from the build computer to the code-signing service. Consider using strong network security for both the build and code-signing networks, including:

Requiring strong authentication and message integrity. Maintaining separate networks for build, code signing, and general use. Installing intrusion-detection and network-monitoring software.

Separation of DutiesOrganizations should use separation of duties to ensure that administrative and operational roles are separated within the code-signing environment and the automated build process. This approach prevents organizational pressures from influencing the overall signing process. For example, one way to implement separation of duties is to create three distinct groups:

One group is responsible for the approval process. A second group controls access to the HSM. A third group is responsible for auditing and process review.


Note:

Important:

Staffing RequirementsOnly highly trusted employees should have a code-signing role. Organizations should consider, for example, having such employees undergo background or credit-rating checks. Other factors that might influence staffing decisions could include seniority, performance, and job satisfaction.

Code-Signing Service Example TopologiesThe purpose of this section is to map the code-signing best practices and general requirements that were discussed earlier to specific deployment scenarios.

Because every organization has different requirements, these topologies provide general guidelines and are not meant to be overly prescriptive. Organizations should consider conducting a formal security analysis to understand what measures are appropriate to protect their identity and reputation. Code-signing service architects must then research and define the specific details of the code-signing infrastructure.

Contact your Microsoft representative for additional assistance in confirming that your customized approach to code signing supports the common goal of platform security and integrity.

This section includes two example scenarios for signing applications:

Example Production Signing Process Engineering Unlock

Each topology includes a different set of security boundaries that are based on the characteristics of the signing environment and the requirements of the signing service. Security boundaries can be defined as physical or logical barriers that control access to sensitive assets and processes. Security boundaries are used to limit access to a small group of highly trusted accountable individuals and trusted infrastructure components. Separation of duties inside security boundaries helps to mitigate reliance on any single individual or team.

Some topics discussed in the previous sections are not included in these example topologies: certificate acquisition, internal CA deployment, test-signing architecture, and key backup. However, code-signing service architects must address these and other issues when designing their specific code-signing infrastructure.

Example Production Signing ProcessProduction Process OverviewThis section describes an example production code-signing process for Windows Phone at the OEM manufacturing site. The section contains definitions for roles, specifies the workflows, and lists the required infrastructure components. The OEM is encouraged to expand upon these guidelines to make the process even more secure in their particular environment. Additional areas such as physical security practices are not covered here, but they are essential for the proper implementation of a secure signing process.

Ownership of ProcessThe production code-signing process for Windows Phone images should be the responsibility of a clearly identified group or department. The group or department should maintain and adhere to the processes detailed in this document for all production images that match the criteria defined in Production Signing Criteria.


Note:

Lifecycle Management for Production Signing CertificatesCreation

A set of production code-signing certificates should be created for the sole purpose of signing images for a single model of a Windows Phone. This is necessary because the ownership of the actual signing for the various models can be different. It is also necessary to ensure that a potential compromise of one or more keys for one model does not affect other models of phones. A set of nine (9) certificates with corresponding keys should be created by the OEM for each Windows Phone model. The certificates can be created by using the Windows Makecert command-line tool. For example, the following command string would generate a certificate.

Makecert –r –a sha1 –ss MY –sp "Microsoft Base Smart Card Crypto Provider" ^ –n CN="OEM.COM(PRODUCTION)" –len 2048 OEM_WP7_E3202ProdCert_N.cer

_N is the running number for the certificates: _1, _2, _3, etc.

The ^ symbol is a line-continuation character for readability; the command is entered on a single line.

The .cer files containing the certificates with the public keys should be checked into the source tree. When the private key is stored on the smart card, the smart card identifier should be logged showing the reference to the specific certificate file, so that this correlation is recorded. For an example of how this can be done, see Using Smart Cards.

Storage

The private keys associated with production certificates are high-value OEM assets and should be kept in safe storage in a secure location. Examples of safe storage are:

1. The hard drive of a computer that is not connected to the network, where the secure password is known to a limited set of trusted employees and is maintained in a secure location.

2. A smart card or USB smart card stick, where private keys are created on the card or stick and are protected with a secure PIN.

3. A hardware security module (HSM) configured according to specification and with the OEM requirements aligned with industry-standard HSM best practices.

Using Smart Cards

Storing the keys that are used for signing on strong, two-factor authentication smart cards is one reasonable approach to key management and security. It can be advantageous to have the smart card systems interoperate with the Microsoft Base Smart Card Cryptographic Service Provider (CSP) and work with Windows workstations.

Gemalto .NET solutions smart cards are one option available on the market to serve as a storage location for private keys. Other options are also available from other vendors such as Thales and SPYRUS. This example scenario assume a Gemalto .NET type of smart card; the general process can be followed for other types of smart cards.

The first step is to create a certificate and key. The private key can be added to the smart card by using the following command line:


Note:

makecert –r –a sha1 –ss MY –sp "Microsoft Base Smart Card Crypto Provider" ^ –n CN="OEM.COM(PRODUCTION_N)" –len 2048 OEM_WP7_E3202_ProdCert_N.cer

The preceding command line allows the Microsoft Smart Card CSP to ask the smart card to create the private key. This way the private key is created on the card and never leaves the card for any signing operation.

Signing an image using the private key can be accomplished using the following command line:

imagehash flash.bin signed_flash.bin 1024 ^ /csp "Microsoft Base Smart Card Crypto Provider" ^ /h 32772 /pad 16 /s MY /n OEM.COM(PRODUCTION)

Specifying the Microsoft Smart Card Crypto Provider and the name of the certificate (/n) causes the ImageHash executable to find the certificate and go straight to the smart card to get the data signed. The smart card will prompt for a PIN before the signing takes place. The Gemalto Smart Card PINs are by default set to 0000; the PIN can be changed by using Windows 7 credential change functionality:

1. Connect a smart card reader and insert the smart card whose PIN is to be changed.2. Press CTRL+ALT+DEL, select Change a password, select Other credentials, and then select Smart Card PIN

Change.3. Enter the old and new PINs and click the arrow (INVALID USE OF SYMBOLS) to complete the operation.

PINs should be kept in a secure location separate from the cards. Theft of a card without a PIN is a less serious problem that theft of both; theft of both means that the keys are compromised.

Never store the cards and the PINs in the same location.

The following is a recommended solution for PIN separation. A book of codes is kept separate from cards. The book maintains a log of card use plus a registry of all card serial numbers with PINs as follows:

Sample Smart Card Registry

Card #

Model S/N PIN Certificate

1 E3202– EU 11204089-1 836542 9369

OEM_WP7_ E3202_EU_ProdCert1.cer

2 E3202 – EU 11232185-1 822367 3339

OEM_WP7_ E3202_EU_ProdCert2.cer

— — — — —

The log book entries look as follows:


Warning:

Sample Smart Card Use Log

Op # Type Role Empl ID Date Approver

(empl ID)

Data 1 Data 2

1 Signing Signer 123804 08102010 120222 Build no: 999

Card S/N

Assm.mbn

(AB345556FDDEFFFFEC)

flash.bin

(AB345556FDDEFFFFEC)

….

2 PIN change Approver 120222 08122010 118291 Card S/N

Old PIN: 9369

Card S/N

New PIN: 4231

3 Card return Signer 123804 08132010 111234 Card S/N

Old PIN: 1234

Card S/N

New PIN: 4241

In the preceding example, the approver has access to release a card with a code to the signer. The release is documented in the log as Operation #1. The type of operation is noted, who the operation was released to, the date, and employee id of approver. The second operation in the sample log is a PIN change operation, performed by an approver, approved by another approver. Because many cards exist and the approver can change the PIN on a regular basis, the signer cannot assume that a card with a particular serial number will have the same PIN the next time the signer gets the same card. When a card is returned to the approver, the PIN should be changed, and the entries in the card registry should be updated to reflect the new value. This operation ensures that all the PINs are unpredictable and verifies that the signer did not change the PIN. The log should be audited on a regular basis to look for issues such as “late return” of cards. Note that the Data1 and Data 2 columns contain specific data about the operation such as build number, file names and hashes to sign, serial numbers of smart cards used, and so on.

Safekeeping of Private Keys

The goal of safekeeping of private keys underlies all the processes in this guide. If private keys are lost, stolen, misused, or misplaced, the entire model of signing images is undermined. The processes defined in this guide should be adhered to with discipline and rigor. The process should be comprehensive yet simple enough that it will be consistently followed end to end. The overall process should contain controls to allow for auditing and feedback for continuous improvement.

When private keys are kept on smart cards, the smart cards should be kept in tamper-proof envelopes in a safe. Signers should obtain the envelopes from the safe when a signing request has been approved..


Production Key Usage

The production signing private keys should only be released for use when approved production signing takes place. The approval process is described later in this guide. Production private keys must not be used for any other purpose.

Production Signing Criteria

Production signing criteria, which determine when an image is approved for production signing, should be consulted by the production signing approver. Recommended production signing criteria should include release criteria signoff from the following stakeholders:

Development manager’s signoff that all source code and features included meet the identified release criteria.

Program management leadership team's signoff that all features scheduled for delivery in image are included.

Test manager’s signoff that all test criteria have been met. Internalization manager’s signoff that all internalization criteria for release have been met. Documentation manager’s signoff that the documentation for release meets release criteria. Device Health manager’s signoff that release meets device health standards (performance, battery

life). Manufacturing manager’s signoff that the image meets all manufacturing release criteria. Serviceability manager’s signoff that the image meets all serviceability release criteria. Other relevant partners’ signoffs based on their release criteria.

Production Signing Schedule

The identified OEM department should appoint a team or person to be responsible for maintaining a production signing schedule. The schedule should specify which builds are to be signed. The recommended signing frequency for a particular phone model is two builds: the release candidate (near complete) and the golden build (last build). The team or person assigned to maintain the signing schedule decides if more than these two builds need to be signed with the production certificate.

RolesThe following roles should be assigned to those responsible for signing control and key management.

Submitter

The submitter is the role assigned to the person who tracks and verifies images that need to be signed. This person is a subject matter expert who understands the build output and release process. The submitter is familiar with the build and signing schedule.

Approver

The approver is the role typically assigned to the team of people who verify that the production signing criteria have been fulfilled.

Signer

The signer is the role assigned to the team of people that participate in the signing event. The OEM can designate a pool of signers (n) from which a smaller number (k) can be drawn to be present at signing. For example, the OEM


could decide that k and n be 2 and 7. This means a total of 7 people know the signing workflow, but only 2 signers need to be present at any given signing event.

Production Signing WorkflowStep 1: Submission of Request

The submitter submits a production signing request to the approver. The submitter provides the approver with build information necessary to determine which images are to be signed.

Step 2: Review of Request

An approver reviews the production signing request and calls a meeting to determine if production signing criteria are met. The meeting is called with approvers, the submitter, and k of n signers present. Before the meeting, the production signing criteria are reviewed and evidence is collected. At the meeting, the approver verifies the information from attendees and approves or rejects the request. The request for production signing is rejected if production signing criteria are not met.

Step 3A/3R: Approval or Rejection Communication

A defined protocol is followed when communicating the signing request approval or rejection. The communication should contain the submission decision, include relevant meeting notes, and specify when the signing will occur.

Step 4: Signing: Private-Key Retrieval

The signers (k of n) perform the signing operation when a request has been approved. The approver is responsible for maintaining the protocol to be used when private keys are obtained. In the case of private keys on smart cards, the smart cards must be retrieved from their secure location before signing can commence. The smart cards should be kept in individual tamper-resistant envelopes in a safe.

Step 5: Signing: Log Updates

The signers (k of n) update the logs. The signers are responsible for keeping an official audit trail of all signing operations. The audit trail should be kept in the safe with the private keys. The signing audit trail should include the signing date, signers' identification, hashes of images signed, build numbers, and image file names.

Step 6: Signing: Operation Complete

The signers (k of n) perform the signing operation using the smart cards and provide the signed image to the submitter. When the signing operation is completed, the smart card PIN operation is performed, and the smart card is placed in a tamper-resistant envelope and returned to the safe.

Example Key-Signing Workflow

The following diagram illustrates one possible key-signing workflow.


Key-Signing Workflow

OperationsThe following operations are part of the Production Signing Workflow.

Private Key Acquisition

To acquire a private key, the signer receives a smart card and PIN code from the approver. The approver owns the signing protocol and the audit trail. The approver retrieves the smart card from a secured location such as a safe, adds an entry to the log, and retrieves the smart card PIN. The PIN is recorded in the smart card registry that is also kept in a secured location.


Role isolation in the build process is strongly recommended. In the OEM key-control department, it is likely that the people responsible for the build process will occupy the submitter and the signer roles. Because of this, they cannot also be responsible for keeping the private keys safe. It is important that the acquisition of a private key for signing not involve individuals from the build team.

Periodic Smart Card PIN Changes

Approvers change smart card PINs on a regular schedule. The approver assigned to change PINs receives approval from another approver. The operation is logged, the old and new PINs are recorded in the log, and the smart card registry is updated with the new PIN.

Smart Card Return

When a smart card is returned after a signing operation, the approver receiving the card creates an entry in the smart card log. The approver also changes the PIN of the smart card at that time to ensure that the PIN has not been changed while out for signing; this also ensures that the PIN is not predictable on subsequent use. When the PIN is changed, the log is updated with an entry for the operation, and the smart card registry is updated with the new PIN.

Audit Log Maintenance

An audit log entry is required for each smart card operation. All fields in the log should be filled in consistently with all required information. In addition to regularly scheduled audits of the log, any inconsistencies in the log should trigger an independent audit.

Backup of Private KeysThe private keys can be backed up using the following guidelines:

Keys stored on a hard drive can be backed up as long as the backed-up copy is handled according to secure protocols. The backup media should be protected and kept in a tamper-proof bag and kept in a safe on-site or off-site.

Keys stored on a smart card or USB smart card stick cannot be backed up. The backup/redundancy solution here lies in keeping many keys on many cards.

Keys stored on an HSM should be backed up following the HSM manufacturer’s guidelines. If the resulting backup results in key files being put on removable media, the media should be handled in the same way as outlined for hard drives.

Disaster Planning for Private KeysAn important part of managing the private key infrastructure is to evaluate the risk of large site disasters and create a strategy for risk reduction. To evaluate this risk, consider what would happen if a fire or other disaster caused all the keys to be lost. If this were to happen, the OEM would no longer be able to produce images. It is therefore imperative that the OEM implement disaster planning procedures for all sites and locations where key material is stored. This means enough keys and backups should exist for OEM production to sustain one disaster at one of its locations, without impacting production and operations at other sites. It also means that production and operations at the site affected by the disaster should be recoverable by using the backed-up keys or other redundancies in the disaster plan. The signing control and key management department is responsible for the disaster plans for the entire private-key solution. PINs and audit trails for smart cards kept on-site should also be kept off-site to insure the integrity of the audit trail during a disaster.


Important:

Example Key Signing and Storage Infrastructure

Destruction of Private Keys Used for Production SigningPrivate keys should be maintained until serviceability requirements for a particular model of phone have expired. Beyond the expiration date of the serviceability of a particular model, the private keys used to sign production images for the model should be destroyed. The private key should be destroyed according to the following general guidelines:

Keys stored on an HSM should be destroyed following recommendations from HSM vendor. Keys stored on a smart card or USB smart card stick should be destroyed by destroying the card or

USB stick according to manufacturer’s recommendations. Keys stored on hard drives should be deleted and files overwritten using a tool that verifiably destroys

the file by overwriting all the sectors of the hard drive the file occupied.

Deployment View of Code Signing InfrastructureThe following diagram shows the deployment architecture of one possible code-signing infrastructure:


Code-Signing Certificate Storage Requirements

Production code-signing certificate(s) protected behind a physical security boundary on code-signing servers

Test code-signing certificate(s) generated with the MakeCert tool; can be stored with source code

Production Code-Signing Server Requirements

Windows Server 2008 R2 or newer (or same as build servers already in place) 6 smart card USB readers (3 each from 2 different vendors, keep 2 off-site) or HSM Servers hardened to removed unnecessary attach surface; best if kept in a safe or unplugged from

network Safe or access-controlled location to prevent unauthorized access to the smart cards that contain the

signing keys

Sample Bill of Materials for Code Signing Lab

Item Name Description Quantity

1 Code-signing servers Standard PC servers with basic build machine configuration.

2

2 USB smart card readers (example vendor: Gemalto, Thales, SPYRUS)

Windows Server compatible; should include the necessary software to provision certificates on the smart cards.

4

3 Smart cards for use with smart card readers

In sufficient quantities to support off-site backup rotation.

10

Engineering UnlockEngineers flash new test and production images onto their test phones on a regular basis. After a phone is flashed with the production image, a special unlock mechanism is needed to allow reflashing with a test image. A sample


process to support this scenario is outlined in this section; OEMs can modify it to create a secure solution that works in their environment.

Ownership of ProcessJust as with production signing, it is important that a specific department have discrete ownership of the engineering unlock certificate management process.

Life Cycle Management for Image Unlock CertificatesCertificate Creation

A set of certificates for production signing and image unlocking should be created for the sole purpose of unlocking engineering devices flashed with production images. It is recommended that one set of certificates be created for each phone model. A set should contain approximately twenty certificates to support a typical OEM development environment.

For production signing, a different set of keys for each phone model is necessary because the ownership of the signing for the various models may be different. It is also necessary to ensure that a breach of one or more keys for one model does not affect other models.

For image unlocking of engineering phones flashed with production images, a separate set of twenty keys should be created. These unlock keys can be used for any phone model.

The following example shows how the certificates can be created by using the MakeCert utility.

Makecert –r –a sha1 –ss MY –sp "Microsoft Base Smart Card Crypto Provider" ^ –n CN=CONTOS.COM(PRODUCTION) –len 2048 Contoso_WP7_A400_ProdCert_N.cer

(_N is the running number for the certificates: _1, _2, _3, etc.)

The .cer files containing the certificates with the public keys should be checked into the source tree.

The smart card used to store a private key corresponding to a .cer file should be logged with reference to the certificate file.

Op #

Type Role Empl ID Date Approver

(empl ID)

Data 1 Data 2

1 PIN change

Approver 120222 08122010 118291 Card S/N

Old PIN: 9369

Card S/N

New PIN: 4231

2 Card return

Signer 123804 08132010 111234 Card S/N

Old PIN: 1234

Card S/N

New PIN: 4241


Op #

Type Role Empl ID Date Approver

(empl ID)

Data 1 Data 2

3 Unlock Unlocker 145267 08132010 111234 Phone S/N Employee ID (of engineer that needs phone unlocked)

Operation 3 in the log handles an unlock scenario. The unlocker gets a smart card with keys to unlock an engineering phone.

Usage

The private keys for image unlock should only be released for engineering unlock operations.

There should be no use of the production private keys other than for properly approved production signing requests as described in Example Production Signing Process.

Image Unlock Criteria

A set of image-unlock criteria is needed to determine when unlock keys can be released to the unlocker. The criteria should limit access as much as possible, but not be overly burdensome so as to block needed engineering work. The criteria will need to be adapted to the unique structure of each organization. Criteria can include the following:

Only full-time employees Only engineers in certain roles Only specific phones identified through serial numbers

Engineering Unlock WorkflowUnlocker Role

The unlocker is the role assigned to the team of individuals that participate in the image-unlock event. The OEM's key-control department can assign n number of unlockers, but only k need to be present at signing. For example, the numbers can be n=7 and k=2. This means 7 people in the unlocker role are approved and able to unlock phones, but only 2 need to be present at the time of an unlock event. In no case should a single individual be able to unlock a phone.

Image Unlock Workflow

STEP 1: SUBMISSION

The submitter submits a request to the approver to unlock a phone (signed with a production image to be reflashed with a test image). The submitter provides the approver with the serial number of the phone.

STEPS 2–3: APPROVAL

The approver reviews the image unlock request and determines if image unlock criteria are met. If the criteria are met, the request is approved; if not, it is rejected. The approver is responsible for maintaining the protocol used when private keys are obtained, securing any smart cards that are used, and keeping an official audit trail of all unlock operations. The audit trail should be kept in the safe with the private keys. The signing audit trail should specify the unlock date, which unlockers were present, and the serial numbers of phones that were unlocked.


STEP 4: IMAGE UNLOCK

The unlockers (k of n) perform the unlock operation when an unlock request has been approved. An important aspect of unlocking is the process that is used to obtain the keys. In the case of private keys on smart cards, the smart cards must be retrieved from their safe location before the unlock process can commence, and the PINs must be managed properly. For additional detail, see Engineering Unlock Operations.

Unlocking an engineering phone flashed with a production image to allow a test image


Engineering Unlock OperationsThe following operations are part of the Engineering Unlock Workflow.

Private Key Acquisition

To acquire a private key, the signer or unlocker receives a smart card with a PIN code from the approver. The approver owns the key protocol and the audit trail. The approver retrieves the smart card from a secured location such as a safe, adds an entry to the log, and retrieves the smart card PIN. The PIN is recorded in the smart card registry that is also kept in a secured location.

Role isolation in the build process is strongly recommended. In the OEM key-control department, it is likely that the people responsible for the build process will occupy the submitter and the unlocker roles. Because of this, they cannot also be responsible for keeping the private keys safe. It is important that the acquisition of a private key for unlocking not involve individuals from the build team.

Periodic Smart Card PIN Changes

Approvers change smart card PINs on a regular schedule. The approver assigned to change PINs receives approval from another approver. The operation is logged, in the log book and the old and new PINs are recorded in the log, and the smart card registry is updated with the new PIN.

Smart Card Return

When a smart cards are returned after an unlock operation, the approver receiving the card creates an entry in the smart card log. The approver also changes the PIN of the smart card at that time to ensure the PIN has not been changed while the smart card was out for unlocking; this also ensures that the PIN is not predictable on subsequent use. When the PIN is changed, the log is updated with an entry for the operation, and the smart card registry is updated with the new PIN.

Audit Log Maintenance

An audit log entry is required for each smart card operation. All fields in the log be filled in consistently with all required information.

Destruction of Private Keys Used for Engineering Signing

Unlock keys can be used for all phone models. It is recommended that all cards regardless of function be renewed on a cycle that is compatible with serviceability requirements. This means that while all unlock keys are common across all models, the smart cards in the card pool can gradually be replaced on a cycle that is compatible with the unlock needs and serviceability requirements of the phones. This is done to decrease the impact of loss or theft of phones or cards. Remember that these keys are only used to unlock internal engineering phones and should be used for no other purpose.

Certificate Management ToolsWindows supports a number of code-signing technologies. This section covers two of these technologies and their related tools.


Important:

Certificate Creation Tool (MakeCert.exe)MakeCert is a certificate-creation tool that generates certificates for test signing. MakeCert creates a code-signing certificate that is either self-signed or signed by the Microsoft Root Agent key. The certificate can be placed in a file, a system certificate store, or both.

For more information on MakeCert, see Configuring System Certificates Stores in this guide and Makecert.exe (Certificate Creation Tool) in the MSDN library.

Certificate Manager (Certmgr.exe)The Certificate Manager tool can be used to view certificates as well as to import them into the certificate store. For more information, see Certmgr.exe (Certificate Manager Tool) in the MSDN library.

Configuring System Certificates StoresThis section discusses several ways to configure system certificate stores:

The Certificate Import Wizard from Windows Explorer and Certificate Import Wizard from the MMC Certificates Snap-In are best used for individual computers.

The Certificate Manager Tool (CertMgr) command-line tool can be used for an individual computer or can be scripted to configure a managed network.

For more information on system certificate stores, including Trusted Root Certification Authorities, Trusted Publishers, and machine and user certificate stores, see Configuring a Test Computer or Environment.

Certificate Import Wizard from Windows ExplorerYou can add a certificate to the system store by starting the Certificate Import Wizard from Windows Explorer.

1. Start Windows Explorer.2. Navigate to the directory that contains the desired certificate file. Supported file types include .cer, .spc,

and .pfx.3. Right-click the certificate file, and then click Install Certificate to start the Certificate Import Wizard. Click

Next.4. Select Place all certificates in the following store, and then click Browse.5. In the Select Certificate Store dialog box, select the desired certificate store, such as Trusted Root

Certification Authorities or Trusted Publishers.6. Click OK, click Next, and then click Finish to complete the procedure.

If the certificate must be placed in multiple certificate stores, repeat the procedure for each store.

This procedure can be used only to add a certificate to the user’s certificate store. It cannot be used to add a certificate to a machine store.

Certificate Import Wizard from the MMC Certificates Snap-InYou can add a certificate to the system store by starting the Certificate Import Wizard from the MMC Certificates snap-in.

1. On the Start menu, click Run, and then type mmc to launch the Microsoft Management Console.2. On the MMC File menu, click Add/Remove Snap-in.


Note:




3. From the list, select Certificates, and then click Add to launch the Certificates Snap-in Wizard.

To add the certificate to a user store, select My user account, and then click Finish. To add the certificate to a machine certificate store, select Computer Account, and then click

Next. In the Select Computer dialog box, select Local Computer, and then click Finish.

4. In the Add or Remove Snap-ins dialog box, click OK.5. In the left pane of the MMC window, expand Certificates, and then click the desired certificate store, such as

Trusted Root Certification Authorities or Trusted Publishers.6. On the Action menu, point to All Tasks, and then click Import to launch the Certificate Import Wizard. Click

Next.7. In the File name edit box, type the name of the file that contains the certificate, and then click Next. An

alternative is to click Browse and navigate to the file.8. Click Place all certificates in the following store, and then click Browse to open the Select Certificate Store

dialog box. From the drop-down list, select Trusted Root Certification Authorities, and then click OK.9. Click Next, and then click Finish.

On Windows Server, there may be slight variations in the steps listed.

Before a test certificate can be added to the Trusted Root Certification Authorities certificate store, the system displays a Security Warning dialog box. Click Yes to allow the certificate to be added.

Certificate Manager Tool (CertMgr)CertMgr is a command-line utility that is distributed as part of the Windows SDK and the Windows Driver Kit. In the context of code signing, it is particularly useful for configuring certificates in test environments that are not part of a domain. This section gives several typical examples of how to use CertMgr.

CertMgr refers to system certificate stores by different names than are used elsewhere in this guide or by the Certificates MMC snap-in.

For successful results with CertMgr, be sure to use the certificate store names in the following examples.

Add a certificate to the system certificate store my:

certmgr.exe -add TestCertFile.cer -s my

Add a certificate to the Trusted Root Certification Authorities user certificate store:

certmgr.exe -add TestCertFile.cer -s -r currentUser root

Common CertMgr arguments:

-add: Adds the certificate in the specified certificate file to the specified certificate store. -s: Specifies that the certificate store is a system store. -r SystemStore: Specifies the system certificate store location. The default location is "currentUser".

Note that adding certificates to the localMachine certificate store requires administrator credentials. For the user store, use "currentUser".


Note:

Note:

For the machine store, use "localMachine". CertificateStore: The certificate store.

For Trusted Publisher, use "trustedPublisher". For Trusted Root Certification Authorities, use "root".

For more information on CertMgr, see Code-Signing Resources.

Code-Signing ResourcesThe following links provide further information about Windows code signing and related topics.

Introductory

Title Location

Cryptographic Services http://go.microsoft.com/fwlink/?LinkId=95779

Introduction to Code Signing http://go.microsoft.com/fwlink/?LinkId=95781

Signing Technologies

Title Location

Deploying Authenticode with Cryptographic Hardware for Secure Software Publishing


Makecert.exe (Certificate Creation Tool) http://go.microsoft.com/fwlink/?LinkId=211849

Certmgr.exe (Certificate Manager Tool) http://go.microsoft.com/fwlink/?LinkId=95775

Signing and Checking Code with Authenticode: http://go.microsoft.com/fwlink/?LinkId=95785

Kernel-Mode Code Signing Walkthrough http://go.microsoft.com/fwlink/?LinkId=211850

Code-Signing Service Best Practices

Title Location

Security Content Overview http://go.microsoft.com/fwlink/?LinkId=211851

Deploying and Managing PKI Inside Microsoft http://go.microsoft.com/fwlink/?LinkId=211852











Title Location

Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure


Designing a Public Key Infrastructure http://go.microsoft.com/fwlink/?LinkId=211856

Windows Server 2003 PKI Operations Guide http://go.microsoft.com/fwlink/?LinkId=211857





Code-Signing BasicsCode signing employs technologies such as keys, certificates, and digital signatures to ensure the identity and integrity of software. This section is an introduction to the basics of code signing. It does not provide a detailed description of cryptography or digital signatures. For more information on that topic, see Code-Signing Resources.

Uses of Code SigningCode-signing techniques use digital signatures to provide identity and integrity for software applications. A valid digital signature:

Identifies the software's publisher. Confirms the integrity of the software by verifying that the software has not been modified since it was

signed.

Digitally signed software, distributed over the Internet, is thus no longer anonymous. By verifying the identity of the software publisher, a signature assures users that they know who provided the software that they are installing or running. Digital signatures also assure users that the software they received is in exactly the same condition as when the publisher signed it.

Code signing does not necessarily guarantee the quality or functionality of software. Digitally signed software can still contain flaws or security vulnerabilities. However, because software vendors’ reputations are based on the quality of their code, there is an incentive to fix these issues.

Digital SignaturesA digital signature binds the publisher's identity to the data that they have published and provides a mechanism to detect tampering. Digital signature algorithms use cryptographic hash functions and asymmetric—or public/private key pair—encryption algorithms. Some digital signatures also take advantage of digital certificates to bind public keys to the identities of software publishers.

To create a digital signature, one must first acquire a key pair. This consists of a public key and a private key, with the following characteristics:

The private key is known only to its owner; the public key can be distributed to anyone. The private key is used to sign the data; the public key is used to verify the signature on the data. The private key cannot practically be calculated from the public key.

In practice, using public-key algorithms to directly sign files is inefficient. Instead, typical code-signing procedures first create a cryptographic hash of the data in a file—also known as a digest—and then sign the hash value with a private key. The signed hash value is then used in the digital signature. The digital signature can be packaged with the data or transmitted separately. A separately transmitted digital signature is known as a detached signature.

A cryptographic hash function is a one-way operation that cannot be easily reversed. If the hash function is sufficiently strong, currently known techniques cannot alter an arbitrary set of data without changing the associated hash value. To verify a file's integrity, a user calculates the hash value of the current contents of the file


Note:

with the same algorithm that was used to create the digest in the signature. If the resulting hash value does not match the digitally signed digest, then the signature, the contents of the file, or some combination has been altered. This renders the signature invalid, and the file should not be installed or run.

The following illustration shows a simplified procedure for signing a file:

1. A hashing algorithm creates a hash value from the data in the file.2. The hash value is signed with the publisher's private key.3. The data and the signed hash are published.

The following illustration shows a simplified process for verifying a signed file:

1. The originator’s public key is used to obtain the original hash value from the signed hash value that is packaged with the data.

2. A new hash value for the data is calculated by using the same algorithm that was used to create the original signed hash value.

3. The hash value that was calculated in step 2 is compared with the hash value from step 1.4. If the two hash values are identical, the data has not been altered and the digital signature is valid.


Digital CertificatesDigital certificates bind an entity, such as an individual, organization, or system, to a specific public/private key pair. Digital certificates can be thought of as electronic credentials that verify the identity of an entity.

Various types of digital certificates are used for a variety of purposes. Examples include:

Secure Multipurpose Internet Mail Extensions (S/MIME) for signing email messages. Secure Sockets Layer (SSL) and Internet Protocol security (IPsec) for authenticating network

connections. Smart cards for logging on to personal computers.

Code-signing certificates allow software publishers or distributors to digitally sign software. Certificates are often contained in digital signatures to verify the origin of the signature. The certificate owner's public key is contained in the certificate and is used to verify the digital signature. This practice avoids having to set up a central facility for distributing the certificates. The certificate owner's private key is kept separately and is known only to the certificate owner.

Software publishers must obtain a certificate from a certification authority (CA), which vouches for the integrity of the certificate. Typically, a CA requires the software publisher to provide unique identifying information. The CA uses this information to authenticate the identity of the requester before issuing the certificate. Software publishers must also agree to abide by the policies that are set by the CA. If they fail to do so, the CA can revoke the certificate.


Identity and PolicyDigital signatures that include digital certificates allow users to make trust decisions by cryptographically verifying the identity of the software publisher whose certificate was used to sign the code. Code-signing policies enable users, administrators, and the Windows platform to make trust decisions in a consistent way.

Certificates and KeysA public key certificate, usually just called a certificate, is a digitally signed statement that’s commonly used for authentication and to help secure information on open networks. A certificate securely binds a public key to the entity that holds the corresponding private key. The issuing CA digitally signs the certificates, and they can be issued for a user, a computer, or a service.

Public key certificates are rooted in asymmetric or public key cryptography. Asymmetric ciphers are built on the unique mathematical relationship that exists between a public and a private key. The public key is the non-secret half of a cryptographic key pair that’s used with a public key algorithm. Public keys are typically used when encrypting a session key, verifying a digital signature, or encrypting data that can be decrypted with the corresponding private key. The private key is the secret half of a cryptographic key pair that’s used with a public key algorithm. Private keys are typically used to digitally sign data or decrypt data that has been encrypted with the corresponding public key.

Most certificates in common use today are based on the X.509v3 certificate standard. X.509v3 stands for version 3 of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) recommendation X.509 for certificate syntax and format. An X.509 certificate includes the public key and information about the person or entity to which the certificate is issued, information about the certificate, plus optional information about the CA issuing the certificate.

The entity that receives the certificate is the subject of the certificate. The issuer and signer of the certificate is a CA.

Typically, certificates contain the following information:

The subject’s public key value The subject’s identifier information, such as the name and email address The validity period (the length of time that the certificate is considered valid) Issuer identifier information The digital signature of the issuer, which attests to the validity of the binding between the subject’s

public key and the subject’s identifier information

A certificate is valid only for the time period specified within it. Every certificate contains Valid From and Valid To dates, which set the boundaries of the validity period. Once a certificate’s validity period has passed, the subject of the now-expired certificate must request a new certificate.

When it becomes necessary to undo the binding that’s asserted in a certificate, the issuer can revoke a certificate. Each issuer (CA) maintains a certificate revocation list (CRL) that programs can use when checking the validity of a certificate.

Roles Within the Code-Signing EcosystemThe code-signing ecosystem consists of several roles. In smaller organizations or in test environments, the same individual might fulfill several roles. In larger organizations or in production code-signing environments, each role is


typically fulfilled by a separate individual or team. The common high-level roles within a code-signing ecosystem are:

Certification authority (CA) Software publisher Software distributor Software consumer

The following illustration shows how the different roles fit together.

Certification AuthoritiesCAs act as trust brokers. They issue certificates to software publishers, binding the publisher's public code-signing key to an identity that software consumers can verify. The policies and operating procedures of CAs vary greatly. However, in general, a CA:

Verifies the identity of the software publisher according to the CA's issuer statement. Issues certificates to software publishers. Revokes certificates if a software publisher's private key is compromised or the publisher violates the

CA's usage practices. CAs revoke certificates by issuing certificate revocation lists (CRLs) or by using the Online Certificate Status Protocol (OCSP).

Protects the CA’s private keys, which are used to sign certificates that are issued to software publishers and to sign revocation information.

Publishes a root certificate or root of trust that consumers can use to verify the identity of the entities to which the CA has issued certificates.

For commercial and government applications, CAs typically deploy a certificate chain, in which each certificate is digitally signed by the certificate above it. A certificate chain normally traces up to a CA's root certificate, creating a hierarchy of trust.


Several commercial CAs issue code-signing certificates whose root certificates ship with the Windows platform and are updated through the Microsoft Root Certificate program.

As an alternative, software publishers and enterprises can use the Microsoft Windows Certificate Server—a feature of some versions of Windows Server®—to issue certificates for use within a managed network or test environment:

For managed network scenarios, an internal CA is useful for signing internal line-of-business applications, scripts, or macros.

For test environment scenarios, an internal CA is useful for testing prerelease software without requiring code to be publicly signed. Additionally, test code-signing certificates can be issued to individual members of development teams to sign private prerelease versions of software with unique certificates.

The manager of the network or test environment uses tools that are built into Windows on the managed network or test lab to trust the root certificate of the internal CA. In these cases, the code-signing certificates are trusted only within the lab or network environment.

Software PublisherA software publisher creates and digitally signs software with a code-signing certificate. The software publisher registers with a CA, requests a code-signing certificate, and agrees to act in accordance with the CA's policies. Software publisher is a broad term and includes a large range of software development activities.

A software publisher must protect its private code-signing key and set up internal code-signing policies and procedures to ensure that only approved code is signed. For more information on this process, see Code-Signing Service Best Practices.

Software DistributorA software distributor publishes software to users. Digital signatures normally ensure the integrity of the software regardless of the distribution method. The distribution mechanism varies. However, if a file is properly signed, it does not matter from a security point of view whether the file is distributed via a web site, FTP site, file share, optical media (CD or DVD), or email.

Software ConsumerA software consumer is any user or application that verifies the digital signatures on software. Without the identity and integrity information in the digital signature, the software consumer cannot make an informed decision about whether to install or run the software.

By default, the Trusted Root Certification Authorities certificate store contains a set of commercial CAs that have met the requirements of the Microsoft Root Certificate Program. Administrators can configure the default set of trusted CAs and install their own private CA for verifying internal software. Note that a private CA is not likely to be trusted outside the administrator's network environment.

A valid digital signature assures the software consumer that an application is strongly identified and has not been tampered with.




Documents

x.509 Certificate Requirementscmsresources.windowsphone.com/.../downloads/Windo… · Web viewConfiguration service providers can be used to provision the phone with settings specific