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.

Continue reading Tokens offer more than token resistance to crackers

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.

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.

Continue reading Troubleshooting Security Problems in Outlook

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.

Continue reading Encrypted email not for everyone

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.

Continue reading Massachussetts extends deadline for encryption law

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.

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.

Continue reading Email Security Measures

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.

Continue reading I’ve Got a Secret – Key, That Is

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.

Continue reading Massachusetts encryption law even stricter than Nevada’s

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.