Administrators confident about the safety of their data encrypted on company laptops should start squirming if a recent court decision passes muster in the United States.

The case involves a Colorado woman who has been ordered to open the encrypted drives on her laptop for federal investigators.

Unlike the cops on television shows and movies, who always seem to have a computer wizard on hand to decrypt a hard drive or crack a password, law enforcement authorities in Colorado, stymied by the encryption on a notebook in the possession of Romona Fricosu, simply went to a judge and asked him to order her to type in her password so they could see what was in the encrypted files.

In arguing against opening the files, Fricosu claimed doing so would violate her civil rights, in particular her Fifth Amendment rights against self-incrimination. Her reasoning was that the government, by forcing her to give up her password for decrypting the drive, were forcing her to incriminate herself if there were anything on the drive tying her to their criminal investigation of a mortgage scam. They believe Friscou is involved the scam that defrauded banks in the Colorado Springs area of some $900,000.

Federal District Court Judge Robert Blackburn didn’t buy that argument. Fricosu might be self-incriminating  herself if she were being asked to utter the password to the files or to give it to the investigators in some other way. However, she was only being asked to type in the password.

The government said it wasn’t interested in knowing what the password was. In fact, it said Fricosu could type the password into the laptop without any government operatives hovering over her. For that reason, the password could be treated like a key is treated in the physical world. Since the courts have ruled that the government can compel someone to give it the key to a safe or other repository of potential evidence in a case, Judge Robinson reasoned, it can compel Fricosu to type in her password.

Although the Fricosu case will be appealed and isn’t settled in law yet, it should give administrators some food for thought. It’s not that far of a stretch, for instance, from treating a password for decrypting files  as a key to treating passwords to anything that way.

That can have broad implications for your data’s security should you ever have to lock horn with any government for any reason. While Fricosu was involved in a criminal matter, the logic underlying the case could be extended to non-criminal government activity such as tax audits or compliance reviews.

With that in mind, should alternatives to passwords be considered? For example, if voice recognition were used to replace passwords, then the “utterance” test might be met and your data might be better protected against intrusive legal searches. Then there’s the question of whether other biometric solutions used for authentication are as legally vulnerable as simple passwords. If a retina has to be supplied to open a laptop, is that a potential act of incrimination?

One thing administrators should take away from the Fricosu decision, should it be upheld by the appellate courts, is that their passwords and the passwords of their organization’s users aren’t as safe as they as they used to be—and neither is anything that can be decrypted with a password.

Government Can Force You to Decrypt Your Data

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

There’s an appealing logic to the notion that as technologies focused on a problem improve, the problem will diminish. That’s not always the case, however, and it may not be so when it comes to plugging email leaks.

Technologies don’t develop in bubbles. While improvements in Data Loss Prevention (DLP) technology are advancing, so are other technologies, technologies and trends that can offset or undermine those improvements.

“You might think the constant progress of technology means more innovative DLP methods will be coming down the pike to prevent sensitive data from being leaked through email and other communications channels,” security expert Jim Rapoza wrote in a white paper published recently by InformationWeek Reports. “But technology is advancing in ways that will make preventing data loss a much tougher task.”

One trend that will make controlling data leaks through email harder than ever is the use of consumer technology in the workplace.

“Many companies are increasingly dealing with the demands of employees (and upper management) who want to use their own devices for business tasks,” he wrote.

“This lets workers take advantage of the latest smartphones and tablets—systems that are likely generations newer than the company could provide—but also adds considerable management headaches, especially in terms of security,” he explained.

Even for administrators who can persuade the brass in their organizations that consumer devices should be kept out of the workplace, enforcing that policy may be more trouble than it’s worth.

“You can ban these devices from your company,” Rapoza wrote, “but chances are good that employees will use them anyway—which only increases the possibility of data leakage.”

As Rapoza explained in his paper, there are a number of ways to control data loss through email, although they can be undermined by the introduction of consumer devices into the office.

For example, encryption can be used to ensure that only the sender and recipient of a message can read it. A drawback to encryption, though, is that a sender and recipient have to coordinate their efforts on a message. That can be cumbersome, although there are systems that automatically manage the exchange of encrypted email within an organization.

Rights management is another way to prevent leakage. It allows rules to be imposed on how a message can be shared, viewed or distributed. You can prohibit a message from being forwarded to someone or shut off “reply to all”. You could bar the message from being sent to an external email address, too. The problem is that rights management may not work on some personal devices brought into work by employees.

Email gateways are another means of staunching leakage. Since they analyze email traffic, consumer devices don’t pose a problem to them. Gateways can be set up to look for content—words, phrases, attachments—that flag errant emails. One drawback to gateways, though, is false positives, which can be annoying to both administrators and their flocks.

And for organizations that need the full metal jacket treatment to prevent leaks, there are Full DLP systems, which combine encryption, rights management and gateways with network and storage policy management and next generation firewalls. That kind of protection is typically priced at six-figures and is costly to maintain on an annual basis to boot.

Plugging Email Leaks Becoming Tougher Than Ever

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In Understanding Email Encryption Part 1 I covered not only why encrypting email is important, but also the two different types of email encryption: asymmetrical and symmetrical.

There was another section that briefly mentioned some of the barriers that impede buy-in from management when it comes to an encryption solution. But these were only touched upon.

Unfortunately when it comes to making a pitch for encryption, those who understand the need for it are an easy sell. Those who either don’t understand it or see the need for it often cite one or more of these stigmas that are attached to email encryption as reason to avoid it.

Should you find yourself being stonewalled when giving your reasons for email encryption, here are a few points you can make to counter any disbelievers.

Of course the consequences that come from disputing your boss in front of others is something that encryption can’t protect against, so use them at your own risk.

Encryption makes us look paranoid

In the previous post I quoted a survey respondent as saying: “normal people don’t encrypt normal email messages” when asked about adopting encryption for email.

The problem is that society does tend to raise an eyebrow at those who act paranoid. Let’s be honest here, they are outright ridiculed.

And no one wants to be made fun of. But that is playground thinking. As a customer, client or employee I want to know that my personal or confidential information is being protected. Email encryption can make me look silly if I am sending a joke to a friend and I use DES cryptography, but if account information is being sent from my bank I want to see a bit of protection put in place.

One way to counter this is to ask, “would you rather someone think you a bit paranoid, or would you rather be in the news like the Oak Ridge Laboratory, CitiGroup, Sony, Target, Chase, etc.”

Encryption is too complicated for most users

15 years ago, email was too complicated for most users. There was a time when the telephone was complicated technology.

And yes, there was a time when cryptography for email messages was quite a bit of work but now it is rather simple and solutions operate seamlessly with your company’s email client.

Outlook offers two separate methods of encrypting email messages. You can encrypt a single message, using 3DES by going to the Message tab in the Options group and click on the Encrypt Message Contents and Attachments button.

After that you simply write your message and send it on its way.

Encrypting all messages can be done as well but that requires all recipients to have your digital ID to decrypt the contents.

Still, that doesn’t seem too difficult now does it?

Encryption is too expensive for us

Another stigma is that encryption is for large companies, not small or medium sized businesses – this isn’t entirely accurate.

Sure, an organization can spend a good deal of money on an expensive appliance that requires add-ons and plug-ins. But you don’t have to spend that much.

With Software as a Service models, even the smallest company can purchase a service contract for only what they need. Be it one user or a thousand.

There are even companies that cater these services to smaller organizations specifically to keep costs within reason.

Software as a Service solutions can also help negate the belief that encryption will be too much of an undertaking for your IT staff as well. Since the company is buying the service, there is nothing for the IT people to set up, configure, troubleshoot, monitor, etc.

Encryption, like any other technology, has changed over the years. But so has the need for it. There was a time when email wasn’t such a lucrative target for attackers. There was a time when regulations mandated certain security baselines be put in place. There was a time when using encryption required a Master’s Degree in Computer Engineering. But all that has changed. Let your company know it’s about time their mentality regarding protecting email messages does as well.

Understanding Email Encryption (Part 2)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

It doesn’t matter if your company uses email to communicate corporate secrets, confidential financial information, or just an invite to the annual picnic; people who weren’t intended to see the message shouldn’t be able to.

To prevent prying eyes from having the opportunity to read your corporate emails encryption is usually the first choice among email administrators who understand security. However, according to a study done by Princeton University titled “Secrecy, Flagging, and Paranoia: Adoption Criteria in Encrypted E-Mail” there are still many barriers to companies implementing email encryption:

• The belief that encryption is not needed because a company is too small
• Encryption flags a message as being important or secret
• Encryption solutions are too complicated for users
• Email encryption solutions are too hard to implement and set up
• Using encryption makes the company look paranoid
• Receiving encrypted messages can be annoying

To quote one respondent of the study, “normal people don’t encrypt normal email messages.”

Lack of understanding

It seems that with so many responses like this, most people have a lack of knowledge when it comes to email encryption.

So let’s start with when someone would want to use encryption. Ask yourself, “Does it matter who reads this email?” For any messages where the answer is no, encryption isn’t necessary.

But if you answer yes, the messages should be secured. Considering 99 percent of all email still travels over the Internet without being secured, it would be safe to assume that there are messages in that 99 percent where the answer to our question would be yes so an understanding of email encryption is certainly warranted.

Types of encryption

There are hundreds of encryption solutions available for home and corporate users. Some are extremely hard to break; others can be broken rather easily by someone who knows what they are doing. Others still have been completely untested. These solutions generally fall under one of two types of encryption: Symmetric or Asymmetric.

Symmetric Key Encryption

A basic definition of symmetric key encryption is where both parties share a single secret key. This works best to prevent casual viewing or the accidental disclosure of sensitive information.

It works by the user typing their email message and, using the shared secret key, encrypting it into cipher text. The cipher text message is then sent to the recipient(s) where the same shared secret key is used to turn the encrypted message back into plain text for reading.

Symmetric key cryptography commonly relies on algorithms such as AES, Twofish, RKZIP, DES, Blowfish and IDEA.

Asymmetric Key Encryption

Also called public-key cryptography, asymmetric encryption requires two separate keys. One is used to encrypt the plain text of the message, called the public key, and another, called the private key, will decrypt the cipher text. The way it works is that a public key and private key are created and mathematically linked to each other. The public key is then published so anyone with access to this key can send encrypted messages to the holder of the private key, which is not shared.

This is very different than the single shared key or symmetric encryption and no longer requires a secure exchange or the single shared key as necessary with symmetric encryption.

The asymmetric method works when the email sender writes the message in plain text and encrypts it using the public key. The encrypted message, now in cipher text, is sent to its intended recipients. The recipient needs to use the sender’s private key to decrypt the message back into plain text so it can be read.

The algorithms that asymmetrical encryption relies on are RSA, PGP, DSA and Diffie-Hellman.

To add an additional layer of security to public-key encryption, some senders use a digital signature as well. The digital signature signs a message with the sender’s private key. Recipients use their public key to verify that the sender is who they claim to be. Not only is the confidentiality of the message now protected, but the authenticity as well.

You can see where this could be used to help fight phishing scams, especially when an internal email address is spoofed to compromise user credentials or steal information.

Even if you decide that encryption should be added to your existing layers of email security, end-users still have to buy in or they will continue to send plain text messages that are not protected. In part two, we will look at some of the stigmas that are associated with using email encryption and how you, as an email administrator, can overcome them with your users.

Understanding Email Encryption (Part 1)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

When you don’t understand something that your job requires you to know, the most logical thing to do is research the topic and learn as much as you can about it. For many people who find security as part of their job description, learning as you go is the only option available. Yet despite the fact that there is so much information readily available to us, misconceptions regarding email security still confuse many professionals tasked with maintaining the confidentiality, integrity and availability of email services.

Blocking executable files will stop malware from being spread among users

Filtering all attachments that include .exe or .msi, was once a common way to keep users from sending infected files to one another through email. This is still considered by many to be a best practice for securing email systems, however as more tech savvy workers entered the workforce, they found ways around this. Generally, people will simply change the extension on a file and send it in an email attachment to a co-worker, friend, or family member. The recipient simply downloads the file and changes it back to the correct file extension. If that file has malware attached to it, the recipient will become infected when the file is opened and that could spread to other machines on your network.

Another scenario that dates this method of securing email, and is much more common, is when a user receives an email with a link in it. This link takes the user to a seemingly harmless website that is hosting drive-by downloads that install malware onto a computer when the person visits the site. No action on the part of the user is necessary other than clicking on the link.

Email security solutions need to address both of these scenarios in order to truly offer protection.

Attackers target large companies because that is where the rewards are greater

We often hear about how large financial institutions are hit by attackers where the number of users whose confidential information is stolen tops up to millions; or maybe it’s an attack against a huge government organization like the Oak Ridge National Lab attack that makes the headlines. At the same time, we almost never hear of a mom and pop store where the same thing happens. That’s because it’s not sensational. A small business being breached doesn’t warrant enough interest from the major networks but that doesn’t mean it never happens. It actually happens more frequently to small and medium sized enterprises than it does to the big corporations.

Large companies often have the budget to better secure email systems against attack where smaller companies often rely on security by obscurity as their solution and attackers know this. Whether they are looking for the lower hanging fruit, or simply trying to hone their skills, SMBs are frequent targets of email security attacks.

Finding security products that are geared towards SMBs is essential not only because they are affordable, but because they are tailored to the needs of these organizations.

Email encryption is only for healthcare and financial institutions.

It is true that these two industries are required by certain regulations to encrypt email messages, while other industries have nothing that says encryption is necessary it still is good practice to make sure your emails aren’t sent in plain text across the Internet.

There are many reasons why a smaller company would want to protect information sent via email. You could be sending confidential information about employees, details about an investigation, sensitive company financial data, strategies for growing your business… the list is endless. But no matter what the reason for keeping a lid on the contents of your message, if it is not encrypted then anyone with the know-how can capture and read these emails.

Email stored behind your firewall is more secure than email stored in the cloud

Cloud security is one of the most hotly debated topics when it comes to email security. Moving email services to the cloud will certainly take security and control out of your hands and put that responsibility on your cloud provider. But that doesn’t always have to be a bad thing.

If you research cloud providers and find one that takes security seriously and is open to answering questions about your email and data, then odds are their staff will be better able to handle security than a small IT department where the staff wears many different hats.

Cloud providers also have multiple data centers to handle back-up and recovery, as well as multiple layers of security.

Getting the right information when it comes to security can be rather difficult. There are many supposed “experts” who make a great deal of money selling snake oil to companies whether it is in the form of a security solution or education. The key is to read as much as you can and always look for the counterpoints when it comes to finding the best solution. If you spend enough time doing your homework up front, you will spend less time in the future dealing with mistakes.

Misconceptions About Email Security

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Advanced persistent threats make email security a necessity

Most email administrators consider security to be a large part of what they do. With so many laws and regulations governing the storage, discovery and retrieval of email messages, security has become a second job to many.

Unfortunately, many administrators either forget, or simply aren’t aware, that securing email requires much more effort than hardening the email servers against attack. In order to fully protect your organization’s email and their contents the mailbox also needs to be defended. Especially when you consider how popular Advanced Persistent Threats are becoming with large cyber crime syndicates who use email not only as a way to harvest sensitive information, but also as a method of attack through phishing and social engineering.

By implementing the following tips into your security plan you can help protect against these, and the many other threats that your organization may face:

Create email policies to regulate the communication of confidential information

Email communication has become second nature in the workplace. It is quick, easy and it gives us a record of our conversation so we can refer back to any information at a later date. However, if the conversation contains sensitive information like login credentials, financials, personal information, and the like, then it can be extremely valuable to anyone who may harvest those emails.

By simply setting up, and enforcing, policies that restrict certain information from being sent via email you can mitigate the damage done if emails are exposed. At the very least, your policy should state that user logins and passwords (and/or PINs) not be communicated via email.

Teach users to encrypt their messages

One of the best analogies I have seen to describe the need for encrypting emails is one that compares email to a postcard. Basically, anyone who comes across it can read the contents if they want. This can be stopped by encrypting emails to prevent eavesdropping.

Encryption is a hard thing for many people. It requires additional steps, training and, in some cases, third-party software (such as PGP) yet it is really the only way to keep your messages private in transit.

Encryption shouldn’t be limited to sending and receiving messages alone. Any email that is stored on a hard drive (think personal folders), a network drive, backup servers or archive systems should also be protected from any prying eyes.

Get rid of old email

A long time ago, storage space was a precious resource. Nowadays inboxes can be easily scaled to hold enormous amounts of data. Unfortunately that provides a greater possibility that an attacker will find something valuable.

Email should be moved, or deleted, when their life cycle is up. Make sure to check with any regulations regarding discovery and archiving before getting rid of the old stuff, but if you combine this with encryption you will be taking great strides to protect older emails.

Practice good network security habits

Make sure that desktops are continually scanned for malware that could possibly expose email login credentials, filter Internet content to protect against malicious websites, understand how to properly use a firewall and update server and client software as needed.

In addition to the employing technology to help secure your email systems you should also consider human factors as well. One of the ways that people first discover that their systems have been compromised is by noticing an anomaly. Be on the lookout for log-ins that just don’t seem right whether it be the IP address, the time of day or even the length of time.

This can be one of the most tedious tasks to undertake when it comes to security but it is by far the most important.

Put the right solutions in place

In many small and medium-sized enterprises, the email administrator alone cannot be as vigilant as he or she would like. Even in organizations where there is team of professionals dedicated to security use necessary security tools to help them do their jobs. Smaller companies need to understand this as well.

By employing technologies that help manage email, backup and recovery, archiving and security, you are plugging the little holes that provide that chink in the armor most attackers are looking for.

No one said that email security is going to be an easy task, but it is one that cannot be ignored just because it’s too hard or it costs too much.

Tips for Better Email Security

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In his article, “Outlook 2003 and RPC Client Access Array Encryption”, Tonino Bruno describes a situation he encountered while deploying Exchange Server 2010 into his environment.

The situation is related to one of the architectural changes that were made to Exchange server 2010. A new RPC Client Access service was introduced which changed how the clients access the server. Outlook MAPI mailbox connections were moved from the back end mailbox servers to the Client Access servers in the middle tier. This new service also changed the Outlook MAPI mailbox connections to be made from the domain controllers/global catalog servers to the Client Access servers in the middle tier in a similar manner. In previous versions Outlook clients made direct RPC connections to the mailbox server. Now, they go to the Client Access Servers. These changes are effected during the deployment of Exchange Server 2010 while creating a RPC Client Access Array.

Note that it is only Exchange 2010 CAS servers deployed prior to Service Pack 1, or upgraded to Service Pack 1, which have this RPC encryption requirement setting which creates an environment for the following problem to occur.

The problem which Tonino described was due to these new architectural changes. It is related to the fact that Exchange Server 2010 has enabled the “encryption required” parameter for the RPC Client Access array. As Tonino explains this is okay for Outlook 2007 and later clients because they also have the RPC Encryption enabled by default. Unfortunately, Outlook 2003 clients do not have RPC Encryption enabled. The result is that RPC Client access for an Outlook 2003 client will fail to connect.

In his article, Tonino recommends the following workaround:

• Disable RPC Encryption on the RPC Client Access array.                                                                                
  Set-RpcClientAccess –Server Exchange_server_name –EncryptionRequired $False
• Deploy a GPO that contains the Outlook 2003 settings to enable RPC Encryption.

An administrator can implement the workaround by disabling the “Encryption Required” parameter on the RPC Client Access Array. This can be accomplished using the Set-RpcClientAccess cmdlet: Set-RpcClientAccess –Server Exchange_server_name –EncryptionRequired $False

Then, on the Outlook 2003 client, the GPO should be validated. Repeat this process for all Outlook 2003 clients. “Encryption Required” can be re-enabled after your GPO has been fully deployed and enabled for all Outlook 2003 clients.

It is good practice to use the Group Policy objects (GPO) to deploy the security templates as this helps to ensure that all servers within the organization are using a consistent security policy. Deploying the Exchange Group Policy Security Templates is more predictable and less prone to configuration problems. The Exchange Group Policy Security Templates can be downloaded from the Microsoft Download Center.

It should be noted that this workaround exists for Exchange Server 2010 RTM where the RPC encryption requirement is an issue with mitigation. This enabled by default “Encryption Requirement” must have been an issue for many administrators because as of Exchange Server 2010 Service Pack 1, the RPC encryption requirement has been disabled by default. Now administrators will not need to enable the RPC encryption feature in their Outlook 2003 clients. It also means that any new Exchange 2010 SP1 Client Access Servers (CAS) deployed in the organization won’t require encryption.

Administrators who are concerned about having the RPC encryption requirement on an Exchange 2010 CAS server disabled needn’t worry about the security between Outlook 2007/2010 and any Exchange 2010 CAS server. The reason why they don’t have to worry is because the RPC communication are still encrypted for these Outlook versions since the client still  has the RPC encryption feature enabled. On the Exchange 2010 CAS server it is only the requirement that is disabled.

As has already been noted, the ability to encrypt MAPI connections in Microsoft Office Outlook 2003 isn’t enabled by default. Some workarounds have already been mentioned above. Another workaround is to make a change to the registry. Administrators can modify or add the following registry key: EnableRPCEncryption.

If an administrator wants to enable encryption of MAPI connectivity between Outlook 2003 and Microsoft Exchange Server 2003 and higher they can manually make the following change:

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\RPC]
“EnableRPCEncryption”=dword:1

The dword value of “1” indicates enable status. The dword value of “0” indicates disable status. If the EnableRPCEncryption registry key does not already exist then add it to the registry.

Remember that RPC encryption is only used for encrypting communications between the Outlook clients and the Exchange Server. For added protection administrators should enforce email security policies which include encryption for specific email messages.

Exchange Server RPC Encryption Requirements

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Encrypting transmissions between servers using SMTP/TLS can protect email from prying eyes, but as with all transport layer encryption, it makes troubleshooting issues on the network much more difficult. With WireShark, or even running debug at the firewall, it is relatively easy to diagnose issues by simply observing the SMTP messages between mail servers to see if there are problems. When those messages are encrypted, your visibility into the network goes away, and you are left with event logs and other diagnostics. One of the more common problem areas you run into when using SMTP/TLS has to do with the certificates in use. Unfortunately, this also results in some of the most cryptic messages you’ve ever seen in event viewer, syslog, or /var/log/mail.d.

Fortunately, you can do some fairly low level troubleshooting of certificate issues with a little OpenSSL magic. If this sounds useful to use, please, read on.

Since most enterprise email systems support SMTP/TLS as a method to securing email transmissions using PKI certificates and the secure exchange of keys, the likelihood of you having to support this is on the rise. As with any other encryption, the tools most admins with a networking background turn to, like protocol analysers, become less and less useful because the very encryption that is intended to secure email also occludes the data exchanges between servers.

Since SMTP certificates are the root of SMTP/TLS, and have to be ‘just so’ before two servers can move on to exchanging email, we need to ensure that they are good to go before moving on to other checks.

To successfully use SMTP/TLS, the certificates used must be

• appropriate for the protocol,
• support digital signatures and key encipherment,
• the CN or SAN must match the hostname of the server presenting the certificate,
• and the client must (usually) trust the issuing CA.

If you are obtaining certificates from a public CA this is usually straightforward, but since more and more organisations are rolling their own to save money, this is not always so straight-forward.

While I roll my own at home, and often will do so at the office for strictly internal purposes, I always recommend that for an enterprise, use only certificates issued by a commercial CA whenever you are supporting connections from clients, customers, or other third parties. The few dollars spent on a certificate from a trusted CA is far cheaper than the efforts troubleshooting issues, or the negative impression a potential customer may get when presented with a warning about your certificate!

You can view the Client Hello and certificate download in WireShark, but sometimes it is easier to just drop to the command line. While Linux based MTAs will have OpenSSL installed already, Windows admins will want to go download OpenSSL for Win32 from Shining Light Productions. First, install the Visual C++ redistributables (linked from that site to MSFT,) then install OpenSSL. Once you have it installed, the commands are essentially the same on Windows and Linux, but we’ll show the Windows cmd prompt syntax below.

1. open a cmd prompt or terminal session.
2. change to the OpenSSL directory. In Windows that will be C:\OpenSSL-Win32\bin by default.
3. issue the following command, substituting the appropriate hostname, and you want to test port 587 as well.

c:\OpenSSL-Win32\bin>openssl s_client -connect demeter.retrohack.com:25 -starttl
 s smtp
 Loading 'screen' into random state - done
 CONNECTED(00000180)
 depth=0 CN = apollo
 verify error:num=20:unable to get local issuer certificate
 verify return:1
 depth=0 CN = apollo
 verify error:num=27:certificate not trusted
 verify return:1
 depth=0 CN = apollo
 verify error:num=21:unable to verify the first certificate
 verify return:1
 ---
 Certificate chain
  0 s:/CN=apollo
    i:/DC=home/DC=olympus/CN=olympus-CA
 ---
 Server certificate
 -----BEGIN CERTIFICATE-----
 MIIEzzCCA7egAwIBAgIKHJPqzQAAAAAAGDANBgkqhkiG9w0BAQUFADBEMRQwEgYK
 CZImiZPyLGQBGRYEaG9tZTEXMBUGCgmSJomT8ixkARkWB29seW1wdXMxEzARBgNV
 BAMTCm9seW1wdXMtQ0EwHhcNMTAwNDMwMTc1MTQ3WhcNMTIwNDI5MTc1MTQ3WjAR
 MQ8wDQYDVQQDEwZhcG9sbG8wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALZ8
 UOsppbvv7hZa6nxaFZAiQ1MKvY+bAUq3MZ7x6KhDIF/rl+9giuEHn+eX4FM81O1L
 fZMK6By/FWaBxMK7Bd51R66csrIUr04JFwAYeCEAx+MYn2WImHPAVF5d5o8dHg09
 IbG3vXquNDKEKIloR/9gnhogfi4szIxI/rDBdp69AgMBAAGjggJ4MIICdDAhBgkr
 BgEEAYI3FAIEFB4SAFcAZQBiAFMAZQByAHYAZQByMAsGA1UdDwQEAwIFoDATBgNV
 HSUEDDAKBggrBgEFBQcDATAvBgkrBgEEAYI3FQoEIjAgMAoGCCsGAQUFBwMBMAoG
 CCsGAQUFBwMCMAYGBFUdJQAwHQYDVR0OBBYEFNiXwZgWEG63djUQAJa7s0oCRVvh
 MDMGA1UdEQQsMCqCFyouZWRhbmRjb25uaWVmaXNoZXIuY29tgg8qLnJldHJvaGFj
 ay5jb20wHwYDVR0jBBgwFoAU8SoB0nFVGBwvTpNt7D5SYQIobnIwgcYGA1UdHwSB
 vjCBuzCBuKCBtaCBsoaBr2xkYXA6Ly8vQ049b2x5bXB1cy1DQSxDTj16ZXVzLENO
 PUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D
 b25maWd1cmF0aW9uLERDPW9seW1wdXMsREM9aG9tZT9jZXJ0aWZpY2F0ZVJldm9j
 YXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQw
 gb0GCCsGAQUFBwEBBIGwMIGtMIGqBggrBgEFBQcwAoaBnWxkYXA6Ly8vQ049b2x5
 bXB1cy1DQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vy
 dmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vbHltcHVzLERDPWhvbWU/Y0FDZXJ0
 aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw
 DQYJKoZIhvcNAQEFBQADggEBADB1neeO9cReyIxyEtEQpyn/nEeeRZ6G4x6aqflB
 /m0YnpIN5C22vQ2FuANaHsJNVi/9U0B5b20V18lM5+6AjMBizadGUv3jcH+jsfT/
 JsHiY0C9NEE6kCUlQfD4YuPjiQvnyGjVVVK3UrIaM4YhH4qXZs21qsCWbaGkybIM
 uk+7viMm1dJoXOHW88ihdqYOwMNxBMbqd61BSWUfn580QV+T9uvz/Q1PF8e8k6Hp
 B8VWbirUh25CfkLdwe2M2Ys1Z+6AppsDf/Y1DQgHgnacWLv784IQBQjHQ45aEHvl
 fwkF3YlWKf7X2iAYmJI0SpwKErFKp8OuziisJi3qKI2NCCU=
 -----END CERTIFICATE-----
 subject=/CN=apollo
 issuer=/DC=home/DC=olympus/CN=olympus-CA
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 1783 bytes and written 443 bytes
 ---
 New, TLSv1/SSLv3, Cipher is AES128-SHA
 Server public key is 1024 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
     Protocol  : TLSv1
     Cipher    : AES128-SHA
     Session-ID: 44030000FDADD13038C7CECB27978C32091B850DAC5FF0B39E6BD48CFE3B7560

     Session-ID-ctx:
     Master-Key: D505277A00EF304B3DF7FE99E72618532A616ABE5A40FA26D0B73647E44BB4BB
 08515582DDD288306B08A51221D21D61
     Key-Arg   : None
     PSK identity: None
     PSK identity hint: None
     Start Time: 1283360267
     Timeout   : 300 (sec)
     Verify return code: 21 (unable to verify the first certificate)
 ---
 250 XSHADOW
 451 4.7.0 Timeout waiting for client input
 read:errno=0

The above example shows an exchange with a server where the admin (me) rolled his own certificate. From our client, we can see that we do not trust* the certificate issuing CA, /DC=home/DC=olympus/CN=olympus-CA.

*OpenSSL on Windows does not use the Windows certificate store, so even if you are running this on a domain joined machine and issued the certificate from an AD integrated PKI, you will still get this error unless you add the CA to OpenSSL’s list of trusted CAs.

Unless our server is configured to accept certificates from untrusted CAs, we are going to either have to trust this root CA, or have the admin of that mail server obtain a certificate from a trusted CA.

See that we can also see the entire certificate. That can help with further troubleshooting name mismatches, etc. Copy everything between —–BEGIN CERTIFICATE—– and  —–END CERTIFICATE—– to a separate text file, save it as a *.cer, and you can open it to view the certificate. From there we can see that this certificate has two wildcard values in the SAN, which should match to the FQDN we connected to.

If we attempt to connect to a server:port that does not support SMTP/TLS, we get this.

C:\OpenSSL-Win32\bin>openssl s_client -connect mail.global.frontbridge.com:25 -s
tarttls smtp -status
Loading 'screen' into random state - done
CONNECTED(00000180)
didn't found starttls in server response, try anyway...
8972:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:.\ssl\s23_lib
.c:184:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 299 bytes and written 254 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Connecting to a server whose CA we trust, and whose certificate has no problems generates a lot less text.

C:\OpenSSL-Win32\bin>openssl s_client -connect mail.global.frontbridge.com:587 -
starttls smtp -status
Loading 'screen' into random state - done
connect: No error
connect:errno=0

With the above in mind, you should be able to easily identify or eliminate certificate issues when troubleshooting SMTP/TLS.

Troubleshooting SMTP/TLS with OpenSSL

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

With token architecture, tokens are substituted for sensitive information on the network.

Encryption has become increasingly important as a means of protecting sensitive information from poachers. As widely publicized data breaches have brought information security under closer scrutiny by governments and industry consumer protection agencies, encryption is no longer an option for many companies but a necessity.

While encryption offers a strong measure of protection for a company’s data, it also imposes additional burdens. For example, encrypted data takes up more space than unencrypted data. that means encrypted data bumps up the demands on a concern’s storage systems. In addition, broad use of encryption can, in some industries, increase the cost of compliance audits, as all systems using encryption must meet the standards of regulators both public and private.

One way to relieve the burden encryption places on organizations that’s gaining popularity is tokenization. Not only does this technology reduce the storage requirements created by encrypting data, but it improves security and curbs compliance costs. The fewer the places that sensitive data is stored in a system, the fewer the places subject to compliance audits.

Tokenization saves space by substituting tokens for encrypted information within a system. Typically when a piece of information is encrypted, it is returned to its original location–a record in a database, for example–in encrypted, or cybertext, form. With tokenization, after information is encrypted, it’s stored in a central location, typically a data vault, and a token representing that data is returned to the original location. That token, which takes up less space than its encrypted analog, can be used anywhere the original information would be used. So if the data is used in multiple locations, space is saved because encrypted forms of it need not be stored at those locations. What’s more, the encrypted data is stored at only one location making it easier to secure.

By their nature, tokens add a level of security to sensitive data. Since the token acts as a pointer to the encrypted data, it contains no sensitive information that could be cracked by a Black Hat. If a cyber thief broke into a database containing credit card numbers that had been tokenized, he or she would leave with a batch of worthless tokens.  In addition, they reduce the number of locations where sensitive data is stored. That reduces the number of places information highwaymen can attack in search of sensitive data. However, while it’s easier to defend a single repository of sensitive information than a web of applications, databases and such containing that kind of data, it does create a juicy target for criminals, just as banks are riper targets for amassing illegal wealth than a citizen standing at an ATM machine.

Another benefit of tokenization is better control over who has access to sensitive information. Access to encrypted data can be restricted to specific employees with authorization to do so and further limits can be placed on who can view decrypted, or cleartext, records.

As valuable as encryption is, it can create problems across data sets, problems that can be alleviated with tokenization. For example, in relational databases, encrypting sensitive fields can upset the referential integrity of the information. A primary key in a customer file–the customer number, for instance–that has been encrypted may not jibe with an encrypted foreign key–say, the same customer number in an order file. That’s because encrypted values are created randomly for security reasons. Although there are ways to make these values consistent, doing so may undermine the security of the process.

With tokenization, that problem is removed because the same token is used throughout the database. The token acting as the primary key in the customer file would be the same as the one in the order file.

Token architectures work best in heterogeneous IT environments that include mainframes, distributed systems for back office systems and an assortment of endpoints. The greater variety of confidential information that needs to be protected, the more valuable a token system can be. Token systems have proved to be very popular in the payments industry. That’s no surprise, since that industry has millions of endpoints–practically anyone who sells anything–which creates a serious security problem. However, the technology is creeping into other sectors that deal with sensitive information such as health care and government agencies.

Tokens offer more than token resistance to crackers

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Gmail has always had an encryption option, but until this week, it has been turned off by default. Now IT people, who tend to be a bit paranoid (but in a good way), would have gone through the trouble to switch on the SSL encryption option, but most ordinary users would simply not be aware that it exists. And for that matter, all those paranoid IT people probably wouldn’t have even used Gmail to begin with.

Google announced last week that it would start encrypting all Gmail traffic. In a blog post, Google noted that they initially rolled out the option to always use https back in 2008. This allows email to be encrypted on the path between the user’s web browser and Google servers. However, when Google first enabled the option, it was off by default. Now, SSL will be used by default, with users gaining the option of selecting “Don’t always use https” from the Settings menu. Some may choose to not enable the extra security option for performance reasons, but in reality, the performance hit will be minor, especially for broadband users—and well worth the extra couple of milliseconds. The login page will still remain encrypted. Using encrypted email can stop several types of attacks, such as man-in-the-middle attacks where an attacker may be snooping email in a public WiFi spot. Using encryption also prevents attacks such as DNS poisoning attacks where a domain name record is hijacked and redirected.

Google decided to make the upgrade just hours after they revealed information about having been victimized by specialized attacks, including certain attacks on Chinese human rights activists’ accounts. Users are cautioned however, not to get lulled into a false sense of security, thinking that turning on Gmail’s encryption option is going to prevent all potential attacks—because it certainly won’t. The same anti-virus, anti-spam and anti-malware software installations should continue in full force, regardless of any added encryption.

With Google making the switch, the next big question is whether the other main free email services like Hotmail or Yahoo! Mail will follow suit; my guess is that they will.

Gmail and encryption

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

There are many areas of Outlook that are potential problems for administrators. Once such area is the sending and receiving of digitally signed messages.

Digitally signing email messages is a form of protection that can be used to prevent identity fraud and the abuse of email messages sent to and from Outlook. Outlook allows email messages to be sent with cryptographic features such as S/MIME digital signatures and encryption.

Such messages can utilize “public key/private key” encryption technology to make private their email messages so that only recipients who possess a public key are able to view the encrypted email message. There is a complicated mathematical relationship between the two keys such that any message encrypted with the public key can only be decrypted using the specific private key. The reverse relationship is also true: any message encrypted with the private key can only be decrypted using the corresponding public key. It is this reverse relationship which supports digital signatures.

Oftentimes you will run across the situation where an end user complains to you that they cannot open a digitally signed message. When they attempt to do so they receive the following warning message: “Signature not trusted.” This is usually an indication that their email system has not implemented email security yet.

If it is a problem with the certificate then an error message will appear that has a red colored X indicating what part of the certificate is having a problem. Your potential solutions can include editing the trust level for the sender’s certificate. Another possible cause of the problem is an outdated or expired certificate.

You can change the trust level of the sender. You should see a Certificate dialog box that will allow you to edit the trust level by clicking on it. You should click on “Explicitly trust this certificate”.

If the problem is with an outdated or expired certificate then, within the same Certificate dialog box, you should click on View Certificate and then click on the Details tab. You will see fields for the “Valid From” and “Valid To” dates. Check to make sure that the certificate has not expired. If it has expired then you can notify the sender of the email using the expired certificate of the expiration status. That sender will most likely have to contact their administrator to create a new certificate.

This process of creating a new certificate will involve an administrator having to contact a trusted third party who is currently storing all of the public keys for the sender’s company. This third party is called a “Certificate Authority” or CA for short. Such a Certificate Authority would be Verisign. Normally a new public/private key pair will have to be generated and the public key sent to Verisign for the authentication process.

What I’ve just described is the problem and solution for when a recipient cannot open a digitally signed message. Sometimes the problem is just the opposite. Your end user has called you to complain that they themselves cannot send an encrypted email message.

When this situation occurs, you, as the administrator, must verify that the email recipient’s digital ID is stored with the address in the contact list or address book. Check for multiple entries. It is possible that your end user had selected and email address for the recipient that did not have the copy of the recipient’s digital ID. They must use the email address for the recipient that includes a copy of the digital ID before they can successfully send the encrypted email message.

If the changes mentioned above do not correct the security problem then you might have to change the security settings for zone.

You can change the zone settings by:

• Clicking on Options from the Tools menu.
• Then click the Security tab.
• Click on the Zone settings
• Click on the OK button or just hit enter when you get the warning box.
• Select Internet for the “Select a web content zone to specify its security settings”. If you want to see content without getting warnings then move the slider bar for the “Security level for this zone” until you select Low. If you want to see the warnings then move the slider bar until you select Medium.

Troubleshooting Security Problems in Outlook

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Kevin Nixon ran a fascinating article on encryption at Information Security Resources yesterday, disputing the need for end-to-end encryption, saying that it’s not such a great idea after all.

I’ve never used encryption for my email personally, though plenty of people do. And for some users, like the President when he’s using his BlackBerry, I’d have to say that it’s essential. But Kevin’s argument bears consideration, especially when applied to ordinary usage.

A couple of simple examples of end-to-end are VPNs, where encryption starts at a VPN client in a remote location, and ends at the VPN server in the main office. Also, SSL–which is used widely over the Web–provides another example: End-to-end starts at the user’s Web browser and ends at the Web server on the back end. The limitation here, according to Kevin, is that the traffic arrives at its destination before being evaluated. He makes a good point. The concept behind end-to-end encryption may be a good one, but it needs an extra step.

Security experts advocate multiple layers of security; for example, both perimeter security and endpoint security are considered essential. But, when traffic (including email) is encrypted, it may not be able to be analyzed by the firewall or by any perimeter-based intrusion detection engines, thereby eliminating the effectiveness of one of multiple layers. Kevin also cites S/MIME as a particular concern, since the contents of an encrypted email cannot be analyzed for malicious content until after it has been decrypted. This means that the malware prevention has to take place on the desktop for the first time–instead of using the desktop security as a “final check” after traffic has already run the gauntlet of other perimeter-based security.

There are some solutions, which involves an extra device or a firewall that is equipped to analyze encrypted traffic; this approach decrypts traffic, analyzes it for malicious content, and then either sends it in the clear or re-crypts it for the rest of the journey.

Encrypted email not for everyone

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

The Massachusetts data security regulation, which has caused some controversy over its stiff requirements (but is still nonetheless a good idea), now has an extended deadline this week, the state changed the deadline from May 1, 2009, to January 1, 2010. This represents the second deadline extension for the law, which was originally scheduled to go live on January 1, 2009.

There was no explanation of the deadline, we can only speculate that the state was bowing to pressure from interest groups to provide more time to comply. This seems to be a trend in government – making laws that require action on the part of companies or individuals, and then routinely extending the deadlines multiple times. Consider the biggest example of this, the DTV switchover. Everybody in the country with a television has been bombarded with messages to get with the program, the government gave out coupons to make sure people that couldn’t afford a converter box could get one, and the industry responded very well with new technology and fabulous new TVs with great resolution. (My wife got me a 42″ flat screen for my last birthday!) But alas, the switchover was delayed, an action that will have at least a temporary ripple effect throughout the telecom industry. Although I’m behind the President on a lot of things, this delay just made no sense at all.

And the delay in Massachusetts is likely more political than based in any sort of reality, just like the DTV switchover delay. Yes, switchovers like the DTV deal, and new regulations like the Massachusetts encryption law, will be messy at first. There’s no avoiding it. No matter how long you wait, there will still be a few stragglers who won’t comply in time, regardless of the number of extensions. Let’s get on with it and let the chips fall where they may.

The Massachusetts law requires any business that collects personal information about a state resident to encrypt all portable devices, wireless transmissions and public networks.

The biggest criticism is the expense involved for small business, and that is indeed a legitimate concern. I’ve read in some articles about the law that there is a requirement to have an employee dedicated solely to security, and from my reading, this is not true. But, let’s look at that one for a moment. First of all, if you’re a mid-size to large company, you already have at least one, if not several, employees dedicated to security, and if you don’t, you should. Naturally, smaller businesses don’t need a full-time security guy, and it would be disastrous to make three- or four-person shops hire an extra person just for this purpose. Even politicians aren’t dumb enough to make such a requirement. Specifically, the regulation requires “Designating one or more employees to maintain the comprehensive information security program.” Nothing is said about requiring a full-time employee. (You can see a checklist of requirements at http://www.mass.gov/Eoca/docs/idtheft/compliance_checklist.pdf.)

According to the state, the cost of compliance for a small business with no more than 10 people is about $3,000, which includes ongoing technical oversight, monitoring, and maintenance. The state report suggests that the ongoing maintenance costs would be “absorbed within any currently existing technical support program, and if none currently exists, should cost no more than $500 per month.” The state’s estimates may be a little on the short side, but definitely in the ballpark.

Massachussetts extends deadline for encryption law

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Massachusetts’ new identity theft regulations, known as the “Standards for the Protection of Personal Information of residents of the Commonwealth”, is running into some opposition from lobby groups and Massachusetts retailers. The strict regulation requires all portable personal information about Massachusetts residents to be encrypted, regardless of whether that data is being emailed over the Internet or not. The rule is designed to add an extra layer of protection on data such as credit card numbers and other personal information. The regulation of course, is a no-brainer, and any business with common sense should be doing this already, regardless of regulation.

But apparently, the business lobby in the state takes exception to the rule, and advocates protested the regulations at a hearing last week. The business owners claim that compliance will be too expensive. However, this argument just doesn’t hold water. Of course, there will be some expenses involved in compliance. However, there have been numerous high-profile data thefts in the news, and the costs involved in cleaning up the mess, the possibility of lawsuits, and the negative public relations is far more costly than just putting in some encryption. In fact, the regulation is just common sense, and when businesses undertake to compile personal information from consumers, they do have a responsibility to protect that information. Laptops and mobile devices in particular are important to protect, since these may contain data that is very valuable to an identity thief, and represent an easy target.

Advocates asked the state to reissue regulations on May 1, and then give businesses two years to comply. The deadline has already been extended from May 1, 2009, to January 1, 2010. The time has come to do something about this situation and stop putting it off. The extended deadline would serve no valuable purpose other than to leave data open and vulnerable for a longer period of time.

Businesses protest Massachusetts encryption law

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Running an email server requires attention to security procedures and policies. How do you prevent unauthorized access? How do you protect your users? How do you ensure the safety of your system?

There are security measures you can take to protect your users and your system from unauthorized use and potentially harmful miscommunications.

One of the first areas to address is application-level security. Data which enters the system can be protected at the application layer before it is passed down the protocol stack. This means that the email text is protected (encrypted) before the email packets are delivered to the intended recipient. This also means that the rest of the email packet – Data link header, Internet header, Transport header and Application Header – is unprotected. Only the email text is protected.

Another security measure to implement is that of Non-repudiation. Non-repudiation means that the author of a message cannot deny being the sender of that message. A message can only be denied if there is a reasonable and credible explanation about why the reputed sender of the message is not truly the author. Non-repudiation is an important aspect of an email system for the purposes of trusted communications.

I’ve discussed the needs for public key pairs (a public and a private key) to enable trusted communications between senders and receivers. You can review the methods of public key pair distribution in a previous post. Remember that distribution of public key pairs is necessary to facilitate trusted communications. Incorrect or corrupted public key pairs can lead to miscommunications or worse, fraudulent communications.

Lastly, email can be sent to either individual recipients or to a group of recipients such as on a mailing list. Care must be taken when using mailing lists because it is harder to encrypt those messages than when sending messages to individuals. Encryption protection can be customized in order that each recipient can retrieve the message in its original unencrypted format.

Email Security Measures

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

How many of you use VPN? VPN stands for Virtual Private Network and if you work for a large company or do business with a large company then chances are you log in to your network via a Virtual Private Network. A VPN is a network within a larger network such as the Internet or a company LAN. But the VPN is not characterized by the physical wires. Instead the VPN uses open connections or virtual circuits through the larger network.

VPNs can enable secure communications over the public network by using authentication or encryption. One of the ways to secure communications of the VPN is by using a shared secret key such as is generated by the Diffie-Hellman cryptographic algorithm.

The Diffie-Hellman key exchange allows two computer users to jointly establish a shared secret key without ever having to know of one another. Later, this key can be used for encrypting subsequent communications across an insecure channel using a symmetric key cipher.  Keep in mind that the Diffie-Hellman algorithm does not encrypt data nor does is it used to make digital signatures. The algorithm is used only for generating a shared secret.

The company I work for uses the Diffie-Hellman key exchange whenever I log in to our VPN either from home or from some other remote location.

The Diffie-Hellman protocol involves the use of prime numbers. The two users first agree on a non-secret public value, S, which is pre-shared between the two users.  The next step requires the two users to generate two values each: a public value, Y, and a private value, X. The private value is generated first and is randomly chosen based on the non-secret pre-shared public value of S. The public value is generated next and is based on the private value using modular exponentiation. Because of the mathematics involved the two values – non-secret pre-shared S and private X value – are mathematically related and it is intractable to determine the private X value if given the non-secret pre-shared S value.

Next, each user’s public Y values are exchanged (traded) between the two users. The final step is for each user to compute a shared secret value, Z, which will be used as a symmetric key. It can also be used as a seed value to generate a symmetric key.  The computation of Z is equal to the public value, Y, taken to the power of X then modulo S. Each user uses the exchanged (traded) value of Y in their computation of Z, the shared secret value.

I’ve Got a Secret – Key, That Is

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

I recently wrote about Arizona’s new law concerning encryption of personal data. Several states are enacting similar legislation, and encrypting such data is becoming a de facto national policy. Most recently, Massachusetts issued new regulations on the same subject last month, and that state’s laws will take effect on January 1, 2009.

The Massachusetts legislation, known as the Standards for the Protection of Personal Information of Residents of the Commonwealth, is very far-reaching and considered the strictest regulations to date. The new law adds to Massachusetts’ already stringent security regulations, by requiring all portable personal data about any Massachusetts resident to be encrypted. This applies to data transmitted over public networks, or that is stored on a laptop, or on any type of removable memory device. The law requires other mandatory security procedures, including updated user authentication and authorization.

There is a technical difference between Nevada’s and Massachusetts’ statute in how encryption is defined. For the Nevada law, “encryption” is defined as the use of a protective or disruptive measure, including cryptography, enciphering, encoding, or a computer contaminant, to render data unintelligible. The Massachusetts statute is more specific, stating that “encryption” is an algorithmic process that requires a confidential process or key to decode. Some have argued that since the Nevada law does not use the word “algorithmic,” then password-protection is adequate to adhere to the letter of the law.

Also, the laws differ in scope. Nevada’s law focuses on the electronic transmission of data, while Massachusetts also includes portability. Accordingly, if you have data on a resident of Massachusetts on your hard drive, even if you do not send it via email or over the Internet, you still must encrypt that data.

Massachusetts encryption law even stricter than Nevada’s

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

I’ve spoken of more than a couple ciphers (cryptographic algorithms) already such as DES, 3DES, RC4, RC5 and RC6. One cipher that I neglected to mention is IDEA (International Date Encryption Algorithm).

IDEA is a block cipher that appeared in 1990. It was developed at the Swiss Federal Institute of Technology by Xuenjia Lai and James Massey. IDEA has a 128-bit key which is more than twice the size of the 56-bit key used in DEs and 3DES’

IDEA is called a block cipher because it operates on 64-bit blocks using a 128-bit key. Part of its operations includes exclusive-ORs, addition modulus and multiplication modulus. It is thought to be immune to differential cryptanalysis under certain conditions. Over the years it has lost its luster due to faster algorithms, issues with patents and little progress in its cryptanalysis.

However, it should be noted that the TLS (Transport Layer Security) group submitted a paper – http://www.ietf.org/internet-drafts/draft-ietf-tls-des-idea-02.txt -  and recommended that DES and IDEA not be used in Transport Layer Security 1.2 main specification. Their reasons for not recommending DES and IDEA include:

• IDEA is a rarely used code and thus is prone to security and interoperability problems
• Most implementations either do not support it, do not enable it by default or do not negotiate it when other algorithms are available.

In 1998, Fortress Technologies became the sole U.S. distributor of the IDEA encryption algorithm by signing a licensing agreement with ASCOM Systec, Ltd., the Swiss conglomerate that owns the IDEA patent.

Ascom is the sole owner of IDEA and holds all intellectual property rights for it. MediaCrypt is the worldwide distributor of the IDEA license. An IDEA license can be purchased from MediaCrypt but at the time of this writing, the MediaCrypt web page had been offline for months.  You can try to contact MediaCrypt AG via the address given in their domain registration. See http://whois.domaintools.com/mediacrypt.com.You also might try contacting someone at Ascom: http://www.ascom.com

The Network Working Group Request For Comments, RFC3058 – “Use of the IDEA Encryption Algorithm in CMS” explains how to incorporate IDEA in Content Management Systems (CMS) and S/MIME (Secure / Multipurpose Internet Mail Extensions) as an additional strong algorithm for symmetric encryption.

As it is, in 2004 TrueCrypt software – free open source on-the-fly disk encryption software – removed IDEA from its product suite.

The IDEA Cipher and Security Encryption

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

So I’ve written about different ciphers recently such as: RC4, RC5, RC6, DES, 3DES, IDEA and AES. And I’ve explained the use of public keys and private keys during the encryption/decryption process.

When using public keys the sender can make available their public keys to their intended receivers through various means like email, fax, etc. But how does a receiver know that the public key which they have received is indeed from the purported sender? How can we be really sure that the owner of a public key is who they say they are?

One method is to mutually rely on a trusted third party to verify the true ownership of a public key. Such a trusted third party is called a Certificate Authority (CA).

Certification Authorities are trusted entities that safely distribute public keys and sign public key certificates. A certificate always contains three pieces of information: a name, a public key and a digital signature computed over the name and the public key. The certificate associates a name with a public key. But how do you obtain a certificate?

Let’s suppose that Paul wants to send his public key to Rhonda so that he can later send a secure email to Rhonda which she will decrypt using Paul’s public key. Both Paul and Rhonda must trust a third party which we’ll call Tim, the CA. Paul requests that Tim, the CA, sign Paul’s certificate that contains Paul’s public key. Tim signs the certificate and now Paul can safely send it to Rhonda. Upon receiving the certificate Rhonda will validate it by checking the digital signature with a copy of Tim’s public key.

You’re probably asking “…but how did Rhonda get Tim’s public key?” As it turns out very few public keys are actually exchanged thanks to the existence of Certificate Authorities. It is the public keys of Certificate Authorities that are manually exchanged by email, fax, etc.

Some well known Certificate Authorities include VeriSign and Thawte. Thawte is owned and operated by VeriSign, Inc (Nasdaq: VRSN). Following acquisition in 2000, thawte continues to prosper as a distinct brand within the VeriSign stable.

Certificate Authorities and Public Keys

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In my last post I talked about encryption algorithms Data Encryption Standard (DES) and triple DES (3DES).

Other encryption algorithms include RC4, RC5, RC6 (proprietary encryption ciphers named after Dr. Ronald Rivest of what is now RSA Security) and the more recently approved standard, Advanced Encryption Standard (AES).

Remember that DES uses a 56-bit key size. It has routinely been attacked over the years and proven to be vulnerable.

AES is a U.S. government standard defined in Federal Information Processing (FIPS) Standard Number 197 in 2001. It is the federal government approved encryption algorithm and can be used up to SECRET level with 128-bit keys and up to TOP SECRET level with 192-bit keys. As such, AES specifies three approved key lengths: 128-bits, 192-bits and 256 bits. The AES standard employs a “symmetric” encryption approach. It requires the same key to be used for encryption and decryption. The AES standard was actually submitted to the AES selection process under the name “Rijndael” by two Belgian cryptographers, Joan Daemen and Vincent Rijmen.

Just a quick side note:  Federal Information Processing Standards Publications (FIPS PUBS  -  http://csrc.nist.gov/publications/) are issued by the National Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to Section 5131 of the Information Technology Management Reform Act of 1996 (Public Law 104-106) and the Computer Security Act of 1987 (Public Law 100-235). Just in case you get curious and want to research this a little more.

Several vendors have come out with products that allow you to send encrypted email messages or to encrypt file attachments with Microsoft Outlook. These products also collect and manage your passwords, both for sending and receiving encrypted files. Most will allow you to use 256-bit keys for encryption. And I have even come across a vendor or two who are using 512-bit keys for encryption of email files.

There are many types of users who would welcome the ability to protect their emails such as: banks, manufacturers, human resource departments, medical professionals, lawyers and social service agencies. Anyone who deals with private information such as social security numbers, bank account numbers, medical records, etc.
Some of these applications will also allow you to create and send a self-decrypting .exe file.
If not self-decrypting then the user must convey the Encryption Key to the recipient of the email by some means other than the email itself. Examples of this include: phone, fax, and courier.

AES Encryption Email

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators