Understanding Security Basics

To begin, you should become familiar with a few terms. Understanding these concepts is the first step toward understanding just how easy it is to secure your applications.

Table 22.1 shows some basic security terms and what they mean.

Algorithms

As stated, an algorithm is the math behind the security. In most cases, the math is being performed on bytes, or arrays of bytes, that make up the data you see on a computer screen. In a simple example, using the numeric ASCII and/or hexadecimal values of characters you can totally change the data a user sees. Listing 22.1 shows a basic algorithm written in Visual Basic 6.0. This sample takes the ASCII value of a character and performs a simple Xor operation against the ASCII value of a character from the password. When the operation is run in reverse, of course, you get your original text back.

Listing 22.1. Basic Encryption/Decryption Algorithm

Public Sub DoCrypt(sPassword as String, sMsgToCrypt as String)
    On Error Goto ErrorHandler
    Dim iLen as Integer, lCode as Long, i as Integer
    iLen = 1
    For i = 1 to Len(sMsgToCrypt)
        lCods = Asc(Mid(sPassword, iLen, 1))
        iLen = iLen + 1
        If iLen > Len(sPassword) Then
            iLen = 1
        End If
        Mid(sMsgToCrypt, i, 1) = Chr(Asc(Mid(sMsgToCrypt, i, 1)) Xor lCode)
    Next
    Exit Sub
    ErrorHandler:
        MsgBox "Error in doCrypt", vbOkOnly
End Sub

The code sample listed will not necessarily work by itself. This is the case with many algorithms as the data being passed to them must often be formatted in some manner or converted to a more basic data type. For example, the Microsoft CryptoAPI requires that most data be converted to the BYTE data type prior to sending it through an encryption algorithm. These algorithms then work by creating or using existing byte arrays to comprise an encrypted message or file.

Sometimes algorithms are written to purposely create a hash that cannot be reversed. This type of hash is useful when you do not want to preserve the original value of the hashed data. In this case an application process would compare a hash as opposed to the data it was created from.

Encryption

Encryption is always the favorite topic around the dinner table isn't it? You spend long hours with the family talking about rearranging letters, numbers, and other characters with unrecognizable trash for the purposes of thwarting hackers and other prying eyes, right? I'm guessing the answer to this question is no; however, encryption is an important—if not the most important—technology available to a developer when securing an application's data. Imagine that a hacker gets through your $40,000 firewall system, figures out that your network administrator password is “password,” and discovers that your administrator password on your SQL Server is “sa”—the encrypted content is still not usable.

For example, if your phone number was stored in a database as (111) 555-1212, and a hacker saw it, it would be pretty easy for them to call you or use your phone for purposes other than what you intended. On the other hand, if your phone number appeared in a hacked database or other file as DKGYD1D3IVdCVEDOCOFE0C3bDI or 8BBEC5B8B51C98E731B09B211564F89ABB4701EA, they would probably have a difficult time figuring out how to dial it. Achieving this is not difficult; it is just a matter of remembering to do it. According to a report from the SANS Institute (http://www.sans.org), of companies that were willing to admit a security breach, $337,000,000 worth of information was lost during the year 2000 alone. That is a lot more expensive than the extra disk space would cost to support the storage of encrypted strings in a database.

BizTalk Server 2002 can process both binary and text-based flat files. This section focuses on the encryption of flat files using string manipulation techniques. Binary encryption is covered in the discussion on Microsoft's Crypto API later on in this chapter.

Listing 22.2 uses the previously listed algorithm to encrypt and decrypt text. The difference here is that although the encryption technique is still simple, the password is now complex. I'm not talking about the typical more-than-eight characters, mixed case and alphanumeric password variety. I am referring to the capability of an application to store the key, a hash of the key, the encrypted key, or an encrypted hash of a key, that you would otherwise never remember, resulting in a much more effective encryption algorithm. A key used in the phone number example might look like this: 7489899049495150535354545757646799696971707272747577767879818083114858587861. It also could look like the key in the first example hash.

Listing 22.2. Simple Encryption and Decryption Routines

Dim sPassword as String, sMsgToCrypt as String, sHex as String
'The above code would need be in the declarations section
Public Function EncryptText(sPass as String, sTextToCrypt as String) as String
    sPassword = sPass
    sMsgToCrypt = sTextToCrypt
    Call DoCrypt(sPassword, sMsgToCrypt)
    Dim sChar as String, i as Integer
    sHex = ""
    'Convert the encrypted text to hex  so that it can be stored as a String
For i = 1 to Len(sMsgToCrypt)
        sChar = Hex(Asc(Mid(sMsgToCrypt, i, 1)))
        If Len(sChar) = 1 Then sChar = "0" + sChar
        sHex = sHex + sChar
    Next
    sHex = Format(Len(sHex), "000") + sHex
    EncryptText = sHex
End Function

Public Function DecryptText(sPass as String, sTextToCrypt as String) as String
'Watch closely for the reversal here
    sHex = sTextToCrypt
    sPassword = sPass
    sHex = Mid(sHex, 4, Val(Left(sHex, 3)))
    sMsgToCrypt = ""
    Dim i as Integer, sTemp as String
    For i = 1 to Len(sHex) Step 2
        sTemp = Mid(sHex, I, 2)
        sMsgToCrypt = sMsgToCrypt + Chr(Val("&H" + sTemp))
    Next
    Call DoCrypt(sPassword, sMsgToCrypt)
    DecryptText = sMsgToCrypt
End Function

Now, you're probably wondering just how secure this encryption method really is given that you now have access to the algorithm and the code. Can't we do anything we want now? Well, not quite. If you can figure out the key I used to encrypt the phone number, let me know. You see, without the key, the code and algorithm are useless. Granted, this probably isn't the most difficult hash to crack, but it definitely beats not having one at all by a long shot.

Encryption in BizTalk Server 2002 can be provided through adding code, like the previous samples, to custom serializers and parsers or through functionality built into the Message Queuing Service. For example, when you specify a port to use for messaging, you can select an encryption method to use as well. Although the BizTalk documentation discusses the use of hardware accelerator cards for encryption/decryption, you can also use custom COM+ objects as application integration components or as preprocessing components to encrypt/decrypt data. Certain levels of encryption are also available through the new Encrypted File System on Windows 2000.

Certificates

By definition, certificates are public keys issued by a certificate authority and placed in certificate stores accessed by computers when needed by a user, application, or machine. Every machine has a unique certificate store, just as each certificate issued by a certificate authority to each different user is unique.

Microsoft Windows 2000, as well as NT, can act as a certificate authority. This provides the capability to create your certificates to be used for secure communications. Certain authorities are public and known to software manufacturers so that their certificates are usually accepted by default, such as Verisign. Because you may not be a “trusted root” authority by default, users usually would be prompted to accept any certificate issued by you. Machines can be set to automatically accept or deny certificates based on machine policies.

Certificates are exchanged between machines to establish or verify identity. This is done through an electronic exchange of information between machines of a protocol such as HTTP (Hypertext Transfer Protocol). When one machine receives a certificate from another machine, it checks a certificate store to see whether the certificate was issued by a valid certificate authority. If the certificate is okay, the information in that certificate is verified against the original issuer of the certificate, and based on that response, a server (or client) can accept or deny access.

Listing 22.3 shows a sample certificate request. After a certificate authority has processed the request, a certificate is generated and installed on the machine that needs to use it. Once installed, this certificate travels back and forth between machines that need this information for security validation.

Listing 22.3. Sample Certificate Request

.-----BEGIN NEW CERTIFICATE REQUEST-----
EIIBnjCCAQcCAQAwXjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAnZhMREwDwYDVQQH
EwhzdGVybGluZzELMAkGA1UEChMCaTMxDDAKBgNVBAsTA2RldjEUMBIGA1UEAxML
aTNzb2x1dGlvbnMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKajbKOvI71N
J6PfiMuuW4GEaFa2SRPo7YtGXSx2cfLgbrT077yAxbfl23EPnrvx92iRwT7ParOg
YaCAaWaANJmtfgJjFJtRwMh7mPJsNg6WoTQEFo2BZnZarDuvWkvpZXdTfsEY5jiw
MXgscOyNiAGew3o/7seWnEMO30YDgRjZAgMBAAGgADANBgkqhkiG9w0BAQQFAAOB
gQCS4gsoIPh/sKxwmPMwbC5nRRnrTYEQECtI59f1p5mMAs4WZ6KWAMGTyrPSJjvt
02C2M9F8TREWUg3SpQ4vx7EluWPKJR/JN4Cex3Ng+zV8/IDW6oP2vUYQMNPlIOGs
gjMIjzUhRlBNIDvu/ScMDWhqSUiAAW3LOZ93J4GTJZuyxw==
-----END NEW CERTIFICATE REQUEST-----

Based on the complexity of this listing, you probably already realize that requests aren't usually hand typed by someone. Many tools are available, including what is available through Windows 2000 Server to assist with the automated generation of certificate requests, including the Certificate Request Wizard in Internet Information Services.

Describing the many types of certificates available and what they all do would be well outside even the scope of this book. If you are thinking about implementing certificate technology with BizTalk, BizTalk recommends that you use machine certificates. A machine certificate is one that is issued as either a client or server certificate, or both. It is accessible from any valid logon on a machine—so no screaming about lack of administrator rights when trying to use one.

The use of certificates in BizTalk Server is essential to its capability to maintain secure communications between servers. In some cases, you may not personally know the person or company on the other side of the world that you are exchanging vital company financial records with. In this situation, certificates are meant to serve as a type of “reference” to assure you that the other party can be trusted. This further adds to the justification of BizTalk's recommendation to use computer certificates. Client certificates are unique to the person who issued them, so their credentials may require their password to access the certificate. BizTalk has to use the credentials of the entity to which the certificate is issued. Unless BizTalk Server 2002 can always run as that person, the certificate is not accessible. Running every service on the machine as a specific user is not generally recommended.

Keys

Keys are essential to security in all aspects. Even for a task as simple as locking your car, a key is necessary to unlock the door of that car, electronically or otherwise. Developing a key strategy can make implementation of security far more successful. A simple key strategy may include using a random number generator to create a key that is used to hash data. The important thing to remember is not to use keys that are easily figured out.

Keys usually come in two flavors, public and private. At times, it may require both keys to unlock data, such as any transaction in BizTalk. This way, you can distribute your public key for distributed information while maintaining your private key for localized data. A private key is used in conjunction with a public key to encrypt/decrypt data or verify identity. Public keys are shared between machines and/or software packages, whereas private keys are specific to a user or machine. This exchange can be seen when entering a Web site over SSL. A certificate is sent from your browser verifying that you are indeed coming from your specific machine. The Web site looks at this certificate, sends that information to the certificate authority (CA), and waits for a response. When it gets that response, it decides whether to let you in.

Hashes

I know what you're thinking, and no I haven't found one yet that rivals a visit to Amsterdam. Many times you will hear something referred to as an “MD5 Hash” or a “SHA-1 Hash.” This simply relates to the algorithm used to generate encrypted or hashed data. Listing 22.4 shows the same data hashed through different algorithms. If you want more information related to a specific algorithm, check with the creator's Web site (http://www.rsa.com).

Listing 22.4. Sample Hashes

Using a Key of 818fd4f63c1eb02e2dbac2bffb18fb5dc3114846
and a text string of Microsoft BizTalk Server Unleashed:
MD2 = 7966B5DF5DA085CDC5730523FE7E94AA4EF21367
MD4 = 110CA589C9ABF812DC12A9622304858D
MD5 = E687DE039C39C7020EE4CF5A5AD48159
SHA-1 = 7966B5DF5DA085CDC5730523FE7E94AA4EF21367

Authentication

Authentication is the process by which a user, program, or machine is validated for identity. Authentication is usually the first step in preventing a malicious attack on your data. Authentication forces your application to maintain the correct identity of all users at all times. Windows 2000 has added a time stamp to its authentication process to prevent what is known as a replay attack. This is where a hacker uses some device, hardware or software, to record or sniff network activity and then plays the recording back against a system or application to try and gain access. In Internet applications, responsible use of session timeout properties on a Web server, as well as use of SSL, can prevent unauthorized users from gaining access to information.

Authorization on the other hand relies on authentication and then uses an Access Control List (ACL) to establish permissions and rights for a user. More detail on Windows 2000 authentication methods is in the section titled “Windows 2000 Security Basics” later in this chapter.

It is recommended that you avoid the use of a plain-text authentication method at all times. This method of authentication is commonly found in Web applications that have clear text authentication turned on or in applications that store unencrypted usernames and passwords in a database. If someone is smart enough to hack into your database, she can certainly write a query to relate a user ID to a user's name, address, and credit card number. Again, even using the simple techniques previously listed can save you much embarrassment in the event of a security breach. Having at least something to answer with is far better than having to answer the question of how the data was left unprotected.

Authentication is the main method of security in Message Queuing Services. Although Message Queuing can accept certificates, it uses a logon procedure based on Windows 2000 authentication schemes before allowing anyone or anything to see the contents of the queue.

Secure Sockets Layer (SSL)

Now that you have an understanding of some of the finer points of security technology, let's take a look at an example of how several of them fit together. The Secure Sockets Layer protocol is a combination of public key exchange and symmetric key exchange. This means that because symmetric key encryption is faster than public key encryption, mostly due to the algorithms used, after a session is established using your public key, the server's public key symmetric key encryption/decryption starts to make data processing more efficient. Symmetric key encryption is also called secret key encryption. This is almost exactly the same as private key encryption. Using two private keys allows for faster operations because the algorithms and the keys, or information used in the certificate, are smaller.

SSL is fully supported by BizTalk Server 2002 and does provide for the secure communication of data over a wire; however, it's probably not enough for most of your application deployments. Consider the items discussed in previous sections of this chapter. Just because the data is encrypted during the transfer does not mean that it is encrypted at any other time during the lifetime of that data.

SSL currently supports at least the following algorithms:

• Triple DES

• DES

• RC2

• RC4

For an excellent article explaining all the steps associated with an SSL exchange, search the Microsoft Knowledge Base for article Q257591.