Windows Cryptographic Programming

Introduction

This article is the first of a multi-part series on the topic of Windows Cryptographic programming. It is provided as a background for the reader so that he or she can enjoy the subsequent articles and techniques. Proper understanding of the terms and concepts will ease the use of the various Cryptographic APIs. Topics to be covered are:

• What is Security
• Security Principals
• User Principals
• Machine Principals
• Service Principal Names
• User Logon Tokens
• Security Access Manager
• Local Security Authority Subsystem
• Security Reference Monitor
• Access Checks
• Kerberos
• Master Keys
• Authentication Service
• Session Keys
• Ticket Granting Service
• Authenticators
• Communication with Kerberos
• Symmetric Encryption
• Asymmetric Encryption
• Signatures
• Crypto API and CAPICOM
• Cryptographic Service Providers
• Base Providers
• Strong and Enhanced Providers
• AES Providers
• S-Channel Providers
• Diffie-Hellman Providers
• Smart Card Providers

What is Security?

Depending on the context, we can view security in many different ways. For example, an ACL on a securable object such as a file is a demonstration of security. This article will touch on most aspects of security, with an emphasis placed on CIA [1]: Confidentiality [2], Integrity [3], and Authentication [4]. The emphasis is due to the intimate relationship between the Crypto APIs, CAPICOM, and CIA.

Confidentiality ensures that our communications stay private. Integrity verifies that our messages have not been tampered with, on disk or in transit. Finally, Authentication proves the identity of the party with whom we are communicating.

Security Principals

By requiring users, machines, and services to have accounts on the local machine or in the Directory, we are provided authentication. That is, we know the other principal is who they claim to be. Because of authentication, we can enforce access control based on the roles of the user or principal.

User Principals

In Windows NT, there was one type of Security Principal. The only entity which had network rights and privileges was a user [5]. Figure 1 shows a typical application of object security on a home directory.

If a process, such as a system service, needed to reach out on the network, we had to add a method for the service to read a username and password, and then have the service logon on using the information. This allowed the service to perform network activities. In this respect, a service or host was trying to mimic a user to gain network access.

Machine Principals

With the advent of the Active Directory in Windows 2000 and above, there are now two security principals: User and Machine [6]. If we need to allow a host or system service to perform an action on the network, the resource is implicitly available since the request is performed using the machine account. Figure 2 shows the Computers folder in the Directory.

Collectively, User and Machine principals are members of the Authenticated Users group [7]. This allows both users and machines to access network resources. Because a machine is now a first class security principal, there is very little need for providing a system service with logon and password information.

Most machine principal security is based on denying access. This is very typical in applying Group Policy. Just as users have group membership, computers can also be grouped. For example, suppose we had two group policies - one for laptops and another for desktops. We can control the application of the GPO based on two groups - Laptops and Desktops. The two group members would consist solely of machine accounts.

Figures 3 and 4 show a Group Policy Object for which the host Newton has been denied access. The result is, host Newton will not apply the GPO.

Further exploring Newton's settings reveals the denial of 'Apply Group Policy'.

Finally, Figure 5 shows the results of applying Group Policy Objects. Notice that the 'Deny Host' policy was filtered due to security. The information was gathered using gpresult.exe.

Service Principal Names

Service Principal Names serve two functions in the directory. First, it acts as a locator service or a connection endpoint. For example, if we wanted to connect to a service on the network, we would need to know the {host name, port number} to reach the daemon. By using a Service Principal Name, we simply ask for the service in the directory. In this respect, an SPN is similar to a CNAME record in DNS.

A second benefit of service principal names is the lack of requirement for a user name and password to access a remote service. This allows us to securely communicate with a remote service without requiring user names and passwords.

Recall that both user and machine principals are members of the Authenticated Users group. In the Active Directory environment, when a system service needs access to a network resource, it will use the machine account to access the remote object. When a client needs to locate and securely connect to a system service, the client will use the service principal name to connect. The Kerberos server will provide the session key for the secure connection.

User Logon Tokens

When a user logs on, an access token is created for the user. The token includes information about the user account, such as group membership and privileges assigned to the user in the directory [8]. This means the token is effectively a Security Context for a process or thread [9]. The token is cached, so if the account is changed in the directory (for example, adding a group membership), the user must log off and then back on to effect the changes.

Security Access Manager

The Security Access Manager (SAM) is a database responsible for local account information, such as usernames and passwords [9]. The database is managed by the SAM Service [9]. Loosely speaking, it is the local machine's equivalent of Active Directory's security accounts database [10].

Local Security Authority Subsystem

The Local Security Authority Subsystem (LSASS) is a user mode process which enforces the local security policy [11]. The local security policy is a collection of security settings for the machine [12]. The settings can be provided by the directory (via a Group Policy object), or constrained on the local machine by the Local Security Policy.

Security Reference Monitor

The Security Reference Monitor (SRM) is part of the Executive Subsystem which manipulates a user's rights, modifies security on a local object, and performs the access check when attempting to manipulate a securable object such as a file [13].

Access Checks

When a user attempts to open or manipulate a securable object, the SRM compares the process' security context (token) against the object's security information. This is performed via the SeAccessCheck in the SRM [14]. Patching two bits in the function would allow a user to gain unfettered access to all local resources [15]. SeAccessCheck is responsible for the familiar ERROR_ACCESS_DENIED.

Kerberos

Kerberos is an authentication protocol which allows principals to securely communicate on the network [16]. The protocol was developed at MIT, and is defined by RFC 1510 (dated 1993). The latest specification is RFC 4120, from July 2005. Microsoft implements version 5.0 of the protocol [17]. The protocol builds upon the authentication provided by Windows. By combining authentication with encryption, we can privately communicate on the network.

Kerberos is the successor to NTLM, or the NT LAN Manager [18]. Kerberos provides two services: Authentication Services (AS), and Ticket Granting Services (TGS) [19]. In Windows networks, Domain Controllers are Kerberos Servers, or KDCs [20].

Master Keys

A principal and the KDC each have a common secret. In the case of a user account, the secret is the password run through a one way function (OWF). This OWF transformed password is referred to as a Master Key. The master key will be used to derive other keys, such as session keys. Note that Microsoft uses the term One Way Function rather than a more specific syntax such as a hash [21].

Authentication Service

Authentication is achieved by requiring the principal to prove knowledge of the master key. Kerberos then verifies the principal's knowledge of the master key using the domain's security database [22]. The KDC does so in the following way. A request for credentials is made by the principal. The server responds by sending a {ticket, random session key} back to the principal, encrypted with the principal's master key.

The principal will decrypt the credentials (the {ticket, random session key}), and then send the {ticket, random session key} back to the server, encrypted with the server's key. When the server decrypts the data, the server will then deem the client (principal) authenticated [21]. The credentials can now be used with the Ticket Granting Service.

A computer booting is similar to a user logging on. Just as a user proves knowledge of a secret to log onto Windows, a computer presents a secret to the Directory to authenticate. Once authenticated, the computer can participate in secure communications with other principals. In the case of a computer account, the computer's secret is created when the System Administrator joins the computer to the domain.

Session Keys

During authentication, a principal obtains a session key by proving it knows a secret. The session key provided by the server is used for encrypting data between the principal and KDC. The session key is randomly created by the KDC, and it is only used for communication between the principal and the KDC. This is known as the logon session key [21].

Other session keys will be used by various principals, but they will be different the session key for use between the principal and the KDC. RFC 4120 refers to these different session keys as sub-session keys [29]. The KDC will create the sub-session keys when requested by authenticated principals.

Ticket Granting Service

When two parties wish to communicate, their first communication is not with one another. Rather, it is with the KDC. A principal will inform the KDC it wishes to communicate with another principal. The request is serviced by the Ticket Granting Service. This request will be encrypted with the logon session key of the principal and the server [21].

The KDC will create a new session key (sub-session key) for use between the two principals. The KDC then sends the newly created session key to both parties. The newly created session key is encrypted with the principal's logon session key. So, the KDC performs two different encryption operations. Each principal will decrypt the newly created session key using its respective logon session key [28].

Each principal will place the newly acquired session key in a cache for later use. The initiating principal will contact the desired principal, which already has a copy of the session key to use in its cache [28]. The two principals can communicate securely, assured that the identity of the other has been established.

Kerberos V5 does support User-to-User authentication, using a request of type ENC-TKT-IN-SKEY [29]. However, Microsoft does not include the implementation [17].

Authenticators

Authenticators are encrypted time stamps so that clients and servers do not fall victim to replay attacks. Because time stamping requires a certain amount of tolerance, RFC 4120 recommends an allowable skew of 5 minutes [29].

Communication with Kerberos

When we wish to communicate securely with the KDC, we encrypt data using a session key. Since we are communicating Kerberos V5, we are using one of the following four encryption protocols [29]:

• AES256-CTS-HMAC-SHA1-96
• AES128-CTS-HMAC-SHA1-96
• DES-CBC-MD5
• DES3-CBC-SHA1-KD

The specification provides a cipher: DES, 3DES, or AES; a mode: CBC or CTS; and an integrity check: SHA1 or MD5. For a discussion of block ciphers, modes, and integrity checks, please see Applied Crypto++: Block Ciphers [24]. The three weakest encryption methods are present for backwards compatibility with earlier versions of Kerberos clients.

Symmetric Encryption

Symmetric Encryption [22] provides us with confidentiality. Symmetric encryption uses a common key shared between two parties. With a shared key, the two parties can securely communicate with one another using either a Block Cipher or a Stream Cipher. Examples of block ciphers are 3DES and AES. Examples of stream ciphers are RC4 and Sosemanuk.

Symmetric Ciphers allow us to encrypt data of an arbitrary length. Most applications of cryptography on bulk data uses this type of a cipher. A treatment of programming using stream ciphers is given in Applied Crypto++: Stream Ciphers [22]. Block ciphers are presented in Cryptography 101 for the .NET Framework [23] and Applied Crypto++: Block Ciphers [24].

When using SSL on the Internet, most of the data is exchanged using the ARC4 (Alleged RC4) symmetric stream cipher [25]. Another example is the stream cipher ORYX, which is the cipher behind digital cellular telephone communications [26].

Asymmetric Encryption

Asymmetric Encryption [27] also provides confidentiality. Examples of asymmetric encryption are RSA and Elliptic Curve Cryptography. While symmetric encryption uses a shared key, asymmetric encryption splits the key into a Public and Private key pair. The keys are related mathematically.

Asymmetric encryption is not well suited for large or arbitrary length messages. This is due to two reasons:

1. public key is orders of magnitude slower than shared key cryptography; and
2. public/private key cannot encrypt data of arbitrary length without some additional work.

Typically, a public/private key pair is used to encrypt a symmetric key.

Signatures

Signatures are used to ensure the integrity of data with authentication. Examples of Signature Systems are RSASS and ESIGN. Signatures use a one way function, combined with a Public/Private key pair.

The use of the Public/Private key pair ensures authentication. This is different than MAC or MIC. Since both parties share the key, it does not provide non-repudiation: either party could have generated the message.

Crypto API and CAPICOM

The Crypto API and CAPICOM provide services that enable us to add encryption and decryption of data and authentication using digital certificates. This allows us to use the functions in CryptoAPI without knowing the details of the underlying implementation. CryptoAPI works with a number of Cryptographic Service Providers that perform the actual cryptographic functions [30].

Cryptographic Service Providers

A Cryptographic Service Provider (CSP) is a special DLL which offers a consistent programming interface. They are special because their loading and use is governed by US export laws and other national laws. To enforce the loading and use described by various governments, a CSP must be digitally signed by Microsoft [31]. The signature will later be verified when loaded by Windows [31]. This means that even though US export laws have been relaxed, other nations' laws may prevent loading of a strong provider.

Base Providers

The feeble CSPs are available in the Microsoft Base Cryptographic Provider, Microsoft Base DSS and Diffie-Hellman Cryptographic Provider, and Microsoft Base DSS Cryptographic Provider. The key sizes are limited to 512 bits for an RSA public-key. The ceiling is 40-bits for RC2 and RC4 keys, and 56 bits for DES. 2DES and 3DES are not available [32].

Strong and Enhanced Providers

For unadulterated cryptography, a typical Windows XP installation will provide the following, in addition to the anemic base providers:

• Microsoft DH SChannel Cryptographic Provider
• Microsoft Enhanced Cryptographic Provider
• Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider
• Microsoft Enhanced RSA and AES Cryptographic Provider
• Microsoft RSA SChannel Cryptographic Provider
• Microsoft Strong Cryptographic Provider

Full provider descriptions may be found in Microsoft Cryptographic Service Providers [36]. There is no great difference between the Strong and Enhanced Providers. Each provider offers a default RSA key length of 1024 bits, and a symmetric cipher default key length of 128 bits [32]. Both the strong and enhanced present a SHA-1 hash (160 bits) [34, 35]. The enhanced providers allow salt to be added to RC2 and RC4 algorithms, while the strong providers do not [32].

AES Providers

The Enhanced AES provider adds AES capabilities with a default key length of 128 bits [33]. This provider also tenders SHA capabilities up to and including 512 bits [34].

S-Channel Providers

The Secure Channel providers implement Secure Socket Layers (SSL) and Transport Layer Security (TLS). SSL was developed by Netscape, and is specified in The SSL Protocol Version 3.0 [44]. TLS is Microsoft's competing technology, and is specified in RFC 2246.

The secure channel is primarily used for Internet applications that require secure Hypertext Transfer Protocol (HTTP) communications [40]. For a complete list of cryptosystems supported, see Cipher Suites in SChannel [41].

TLS is a superset of SSL. Microsoft S-Channel providers support versions 2.0 and 3.0 of SSL [38]; and version 1.0 and 2.0 of TLS [39]. Both TLS and SSL support HTTP over their respective transport technology [42, 43]. Each differentiates insecure from secure traffic through the use of a distinguished port number (443). RFC 2817 is a companion to RFC 2246, specifying HTTP over TLS without a distinguished port number.

Diffie-Hellman Providers

The Diffie-Hellman providers allow us to exchange keys for use in creating a secure channel. In a domain environment, Kerberos ensures authenticated principals securely receive keys for authentication and private communication.

In an untrusted environment, such as the Internet, the ability to create a secure channel on the fly is realized through Diffie-Hellman key exchange. DH is based on a discrete logarithms problem (finding logarithmic roots in a finite field). Once the channel is in place, symmetric keys are exchanged for bulk encryption operations.

Smart Card Providers

Smart Card providers for a Windows XP installation include the following:

• Schlumberger Cryptographic Service Provider
• Gemplus GemSAFE Card CSP
• Infineon SICRYPT Base Smart Card CSP

These providers offer Smart Card and PIN management services for use in CAPI programming. Infineon SICRYPT Base Smart Card CSP does not appear to be available to a Windows 2000 installation.

References

1. CIA Triad, accessed December 2007.
2. Confidentiality, accessed December 2007.
3. Integrity, accessed December 2007.
4. Authentication, accessed December 2007.
5. Domain Migration Cookbook, Chapter 1: Security, accessed December 2007.
6. Microsoft Windows 2000 Security Configuration, accessed December 2007.
7. J. Richter and J. Clark, Programming Server Side Applications for Windows 2000, Microsoft Press, 1999, ISBN 0-7356-0753-2, p. 493.
8. M. Russinovich and D. Solomon, Microsoft Windows Internals, 4ed, Microsoft Press, 2005, ISBN 9-780735-61917-3, p. 488.
9. K. Brown, The .NET Developers Guide to Security, Addison-Wesley, 2004, ISBN 0-3212-2835-9, p. 299.
10. M. Russinovich and D. Solomon, Microsoft Windows Internals, 4ed, Microsoft Press, 2005, ISBN 9-780735-61917-3, p. 489.
11. M. Russinovich and D. Solomon, Microsoft Windows Internals, 4ed, Microsoft Press, 2005, ISBN 9-780735-61917-3, p. 489.
12. M. Russinovich and D. Solomon, Microsoft Windows Internals, 4ed, Microsoft Press, 2005, ISBN 9-780735-61917-3, p. 488-89.
13. M. Russinovich and D. Solomon, Microsoft Windows Internals, 4ed, Microsoft Press, 2005, ISBN 9-780735-61917-3, p. 493-94.
14. G. Hoglund and G. McGraw, Exploiting Software: How to Break Code, Addison-Wesley, 2004, ISBN 0-2017-8965-8.
15. K. Brown, The .NET Developers Guide to Security, Addison-Wesley, 2004, ISBN 0-3212-2835-9, p. 299.
16. Basic Overview of Kerberos User Authentication Protocol in Windows 2000, accessed December 2007.
17. M. Walla, Kerberos Explained, accessed December 2007.
18. K. Brown, The .NET Developers Guide to Security, Addison-Wesley, 2004, ISBN 0-3212-2835-9, p. 300.
19. Basic Overview of Kerberos User Authentication Protocol in Windows 2000, accessed December 2007.
20. Applied Crypto++: Stream Ciphers, accessed December 2007.
21. Cryptography 101 for the .NET Framework, accessed December 2007.
22. Applied Crypto++: Block Ciphers, accessed December 2007.
23. Symmetric-Key Algorithms, accessed December 2007.
24. ARC4 Stream Cipher, accessed December 2007.
25. ORYX, accessed December 2007.
26. Public Key Cryptography, accessed December 2007.
27. Kerberos V5, RFC 4120, Section 8.2, Specification 2.
28. Cryptography, CryptoAPI, and CAPICOM, accessed December 2007.
29. Policy for CSP Vendors Outside North America, accessed December 2007.
30. Cryptographic Service Provider, accessed December 2007.
31. Microsoft Enhanced Cryptographic Provider, accessed December 2007.
32. Microsoft AES Cryptographic Provider, accessed December 2007.
33. AES Provider Algorithms, accessed December 2007.
34. Microsoft Strong Cryptographic Provider, accessed December 2007.
35. Microsoft Cryptographic Service Providers, accessed December 2007.
36. TLS Versus SSL, accessed December 2007.
37. Secure Sockets Layer Protocol, accessed December 2007.
38. Transport Layer Security Protocol, accessed December 2007.
39. Secure Channel, accessed December 2007.
40. Cipher Suites in SChannel, accessed December 2007.
41. HTTP Over TLS, RFC 2818, May 2000.
42. The SSL Protocol Version 3.0, November 1996.

Revisions

• 12.13.2007 - Initial release.