Consider the URL example.com/?user=123&account=456 and then imaging what a hacker could do with it. Security or not, sometimes you just don’t want the visitors to see all the query strings for whatever reason.

In those cases it would be nice if we could encrypt the entire query string so it wouldn’t carry any readable information. The problem with one big encrypted query string is that we would break all the code that referenced the query. Code like Request.QueryString["user"] would no longer work, but as usual ASP.NET has the answer to that problem.

What we need is an HttpModule that can turn the encrypted query string into a normal readable one, so that we can still use our old logic like Request.QueryString["user"]. In other words, we want the user to see this

?enc=VXzal017xHwKKPolDWQJoLACDqQ0fE//wGkgvRTdG/GgXIBDd1

while your code sees this

?user=123&account=456.

The HttpModule

The module we need for this task must be able to do a few simple things. It must be able to encrypt the regular query string so that all your current links will automatically be encrypted. It must also be able to decrypt it again so that you can write the code as you normally would. It must also provide a method for encrypting a regular query string if you don’t want to use automatic encryption.

The most important feature of the module is to make it totally plug ‘n play. You should be able to apply the module to any existing website and automatically have query string encryption and decryption without changing any of your code.

Implementation

Download the QueryStringModule.cs below and put it in the App_Code folder of your website. Then add the following lines to the web.config’s section:

<httpModules>

</httpModules>

Because automatic encryption is not always desirable the module has a comment that tells you how to turn it off. The module is well commented and should be easy to modify for any ASP.NET developer.

Example

You can encrypt query strings by using the Encrypt() method of the module from any web page or user control.

string query = QueryStringModule.Encrypt("user=123&account=456");

Then just add the encrypted query string to the links that need encryption. You don’t need to use the method if you use automatic encryption.

Download

QueryStringModule.zip (1,55 KB)

Comments

Tag:

Reddit | Furl

Bookmark WebProNews:

Mads Kristensen currently works as a Senior Developer at Traceworks located
in Copenhagen, Denmark. Mads graduated from Copenhagen Technical Academy with a multimedia degree in
2003, but has been a professional developer since 2000. His main focus is on ASP.NET but is responsible for Winforms, Windows- and
web services in his daily work as well. A true .NET developer with great passion for the simple solution.

http://www.madskristensen.dk/

Embarrassing data losses by the Department of Veterans Affairs and the Internal Revenue Service have led the Office of Management and Budget to issue a memorandum on encrypting personally identifiable information when it is taken away from the office.

Agencies have until August to comply with the OMB request. This will enable them to compensate for a lower level of physical security when data leaves the confines of a secure facility.

The data security company GuardianEdge released a white paper on the topic to assist those agencies in complying with OMB.

“This White Paper is a one-stop companion guide for completing the NIST security checklist and achieving the objectives set forth by the OMB memo, providing key information about how to properly identify and protect PII in a timely and cost-effective manner,” the company said.

On the syndication side of the world, there is a new way to tag RSS feeds.

Called GeoRSS, the Open Geospatial Consortium (OGC) has developed it as a way for feed creators to place location information into those feeds.

The OGC GeoRSS White Paper discussed the proposal, and cited GeoRSS as “important stepping stone in the evolution of the geo-semantic web.”

World Wide Web inventor Tim Berners-Lee has espoused the Semantic Web concept; it also has a place in a W3C project.

That project has noted challenges exist when it comes to placing geospatial information into online content; we think those challenges will exist for GeoRSS as well.

Discuss this article with your fellow WebPros at WebProWorld.
—

Add to Del.icio.us | Digg | Yahoo! My Web | Furl

Bookmark WebProNews:

David Utter is a staff writer for WebProNews covering technology and business.

Disk Utility

Disk Utility needs to work from a folder, so you first need to create a directory to put your protected files in. I used “secrets” as my directory name, and moved my important files into it. I then invoked (in Terminal):

hdiutil create -encryption -stdinpass -srcfolder secrets foo.dmg

You can also do this with the graphical Disk Utility tool. This will ask for an encryption passphrase, or you could just do:

echo "your passphrase" | hdiutil create -encryption -stdinpass -srcfolder secrets foo.dmg

This creates “foo.dmg” and the passphrase you used is required to open it. If you do that graphically through Finder, you’ll be prompted for your phrase, or you can do it from the command line:

hdiutil attach -stdinpass foo.dmg

Entering the correct passphrase gives you a mounted disk image where you can access your files. By the way, don’t forget to remove the “secrets” directory and its contents.. not much point in encrypting a disk image of a folder and leaving the unencrypted version on the disk.

GNU Privacy Guard

You can download this from http://macgpg.sourceforge.net/. Run the installer, and then at the Terminal command line run:

gpg --gen-key

This asks a few questions, including requesting a passphrase, and generates the files it needs. Generating these will take a fair amount of time – you need patience. You also need your machine to be doing something; I did “ls -lR /” in a terminal window while continuing with my ordinary work. Eventually gpg will finish up:

gpg: /Users/apl/.gnupg/trustdb.gpg: trustdb created
gpg: key 5D604AE8 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 1024D/5D604AE8 2006-05-14
Key fingerprint = F08A C9DC 53DF AF02 8E50 B683 2A0B 47EC 5D60 4AE8
uid Tony Lawrence (Key for files)
sub 4096g/100D68F5 2006-05-14

For simple use, gpg is very easy. For example, given a file “stuff”:

gpg -e stuff

is all you need. That will ask for a user id (you provided that when you created the gpg keys) and will create “stuff.gpg”. This does not remove “stuff”, so if you are using this to protect files on your disk, remove the original. To decrypt, “gpg stuff.gpg”. For that, you’ll need your passphrase.

For more on gpg in general, see GPG/PGP Basics and for more on integrating GNU Privacy Guard with Mac OS X programs, see Configuring GnuPG (Mac OS X)

*Originally published at APLawrence.com

Add to Del.icio.us | DiggThis | Yahoo! My Web | Furl

A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com

Fortunately, encryption is built into wireless technology; it’s simply a matter knowing how to turn it on.

Wired Equivalent Privacy (WEP) or WiFi Protected Access (WPA)

The good news is that wireless technology does have pre-built security but the bad news is there’s a flaw in that security. The problem lies in the fact that it’s been built upon two completely incompatible standards with the result being that it’s a pain in the “you know what” to set up a whole network to use encryption.

Like most new technologies it starts out using a certain standard and then as the technology evolves better ways are developed that make the original technology obsolete. Flaws are also exposed in the original standard that make it less desirable. Problems then develop as business and individuals scramble to transition from the old to the new because during the transition there’s always equipment and devices that use the old technology and the differences usually cause compatibility issues.

WEP was the original standard for encryption over 802.11 wireless networks but in 2001 a research paper was published entitled: “Weaknesses in the Key Scheduling Algorithm of RC4″ which demonstrated critical flaws in the security of WEP that made it rather simple for someone with reasonable know how to break it and have access to someone’s network.

In a nutshell, WEP made it too easy to discover its’ secret key and once you have the key; you can hack in and stay for as long as you want. Owners quickly recognized that it was virtually useless to use WEP on their networks but by the time the industry discovered the security flaw the WEP method was built into almost every piece of wireless equipment made.

Clearly, the WEP standard had to be replaced and in 2003 WPA was introduced and fortunately it fixed most of its predecessor’s flaws. WPA is much more secure than WEP. Unfortunately, WPA took a long time to reach the market and WPA devices were rather expensive when first released. As a result, WEP was and still is the default in a high percentage of the software being used because it’s supported by more devices. Now you can see why we find ourselves in the confused situation we are today.

WPA is the Here and Now

If you plan on to enable encryption, always use WPA. Any devices purchased after 2003 should be WPA compatible because the upgrade was made a mandatory part of the standard.

Without a doubt WEP is better than nothing because it will; at least, deter the casual intruder, who won’t try anything more than double-clicking to gain access to your network. In addition, WEP can also make you less of a target for wardrivers because there’s so many completely open networks that are even easier targets than those using WEP that they simply access them. However, it’s silly to use WEP nowadays (post 2003) when WPA is so easily available.

Encryption – Turning It On

Actually turning on encryption in Windows is fairly easy. The problem isn’t complexity it’s time or aggravation because it does involve a fair amount of clicking which is probably why so few people bother.

Step one is to turn on encryption for your wireless router or access point. The exact method will vary between devices but you can usually do it by visiting the router or access point’s configuration page in your web browser, find the encryption settings and then choosing WPA. If you have any trouble, refer to your manual.

Once you’ve done that, you’ll need to change the encryption settings on your computers. Open the “View Available Wireless Networks” screen by right-clicking on your wireless connection (bottom right of your screen) and selecting it from the menu that appears. Next, click “Change advanced settings” go to the Wireless Networks section and click your network’s name and then click Properties.

Next, where it says “Network authentication” select WPA and click OK on everything you’ve opened. Really not that bad but then again, that’s not the fun part. The fun comes when you get to do this for “every computer on your network”. Sorry to be the bearer of bad news but grab a latte, put your feet up and start clicking.

Easier for New Networks

As you can see, the process is your basic “pain in buns” for existing networks but fortunately it’s much easier for networks that have not been set up. You still need to turn on encryption at the wireless router or access point but once you’ve done that you can set up encryption using the Wireless Network Setup Wizard.

You’ll have to ask Mr. Gates about this one but for some reason Windows still turns on WEP by default when you set up your wireless network. What this means is that each time you go through the wizard, you’ll need to remember to check the box on the third screen that says “Use WPA encryption instead of WEP”. A pain, but it’s still easier than changing the settings manually down the road.

Kevin Erickson is an entrepreneur and writer.
For more articles he’s written visit: http://www.zephyrnet.com |
http://www.eyeonvoip.com | http://www.usfairtrade.com

Both the <EncryptionMethod> and <KeyInfo> are optional i.e. the sender and receiver may agree on the encryption method and key in advance. Several elements use the definitions from the DSIG.

If the recipient does not know the decryption key in advance, then the sender generates and sends it. The key can be protected in transit by encrypting method or key agreement.

If the plaintext data to encrypt is an XML element or content, you encode it using UTF-8 and perform any necessary transforms to it, otherwise, if it is an external resource, you simply consider it as an octet sequence. You then encrypt the data, creating CipherValue, which you place in EncryptedData.

Care must be taken when signing content that may later be encrypted; clearly; the content must be restored to exactly the original plaintext form for the signature to validate properly. To restore the plaintext in the signed content, use the decryption transform method for XML signature defined by the XML encrypt joint W3C and IETF working group.

This transform also allows specifications of XML fragments that were encrypted and then signed with rest of the document and, therefore, are not decrypted to validate the signature. Often, encrypted fragments are removed from the signed information by using the XPATH transform in the reference element, since the meaningful information is the plaintext.

We can sign the plaintext version of an encrypted element by including the appropriate reference element pointing to it. When the signed document is confidential and encrypted after being signed, you should also protect against surreptitious forwarding in which the recipient forwards the signed confidential document to a competitor, encrypted by the competitor public key, trying to make it look as if the sender sent the confidential information. To prevent surreptitious forwarding, the signer should append the recipient identities to the document being signed.

If the recipient does not know the decryption key in advance, then the sender generates and sends it. The key can be protected in transit by encrypting method or key agreement.

If the plaintext data to encrypt is an XML element or content, you encode it using UTF-8 and perform any necessary transforms to it, otherwise, if it is an external resource, you simply consider it as an octet sequence. You then encrypt the data, creating CipherValue, which you place in EncryptedData.

Care must be taken when signing content that may later be encrypted; clearly; the content must be restored to exactly the original plaintext form for the signature to validate properly. To restore the plaintext in the signed content, use the decryption transform method for XML signature defined by the XML encrypt joint W3C and IETF working group.

This transform also allows specifications of XML fragments that were encrypted and then signed with rest of the document and, therefore, are not decrypted to validate the signature. Often, encrypted fragments are removed from the signed information by using the XPATH transform in the reference element, since the meaningful information is the plaintext.

We can sign the plaintext version of an encrypted element by including the appropriate reference element pointing to it. When the signed document is confidential and encrypted after being signed, you should also protect against surreptitious forwarding in which the recipient forwards the signed confidential document to a competitor, encrypted by the competitor public key, trying to make it look as if the sender sent the confidential information. To prevent surreptitious forwarding, the signer should append the recipient identities to the document being signed.

Pawan Bangar, Technical Director, Birbals, #1047,Sector 42-b, Chandigarh. www.ebirbals.com, www.birbals.com

Using social engineering tactics, fraudsters ensure that the trust relationship established by a company with its customers is exploited to maximum effect. It is for this reason that moving towards stronger identity assurance techniques is the only long term strategy that will maintain the stability of the Internet.

Identity and authentication are fundamental concepts in every marketplace. People and institutions establish trust before conducting business. Traditionally there has been a reliance on physical credentials such as a business license or a letter of intent. In the age of the Internet, e-business will only succeed if this ability to pass trust remains consistent. Authenticated SSL certificates have been proven to provide the critical online identity assurance necessary to establish trust between parties. In fact the future success of a multitude of e-commerce eco- systems rests directly upon the continual strengthening of that trust relationship.

WHY DO WE NEED ENCRYPTION?

The Web presents a unique set of trust issues, which businesses must address at the outset to minimize risk. Consumers submit information and purchase goods or services via the Internet only when they are confident that their personal information, such as credit card numbers and financial data, is secure. The solution for businesses reliant upon e-commerce is to implement a complete e-commerce trust infrastructure based on encryption technology. Let us take a closer look at “encryption”. The dictionary definition is:

1. To put into code or cipher.

2. Computer Science. To alter (a file, for example) using a secret code so as to be unintelligible to unauthorized parties.

3. The manipulation of data to prevent accurate interpretation by all but those for whom the data is intended. Financial institutions use encryption to increase the security of data transmitted via the Internet.

So in essence encryption is the process of transforming information to make it unintelligible to all unauthorized parties except the intended recipient and forms the basis of data integrity and privacy which is necessary for e-commerce. What this means is that the whole purpose of encryption is to make sure that the intended recipient is the only one who receives in intelligible form the information which has been encrypted.

Unless you have authenticated the “intended recipient” how do you know who that entity is? The answer is you don’t! So it would be fair to say from the definitions above that, if you don’t know who you are encrypting for, then encryption is potentially pointless.

“High Assurance” certificate authorities (CAs) perform that authentication for you with due diligence, and put their name to this in the SSL certificates which they sign. This is not done by “Low Assurance” CAs which issue SSL certificates providing encryption of dubious worth. Let’s look more specifically at other legal, technical and commercial issues facing consumers and businesses where entity authentication is not performed.

Should consumers take the 60,000,000:1 gamble on privacy and confidentiality?

Today, new web site registrations are running at approximately 5 million new domains per quarter with a cumulative total of over 60 Million . Without a pre-existing trust relationship, consumers have no trusted method available to verify the ownership of a web site and therefore are completely reliant upon the entity authentication processes performed by Certification Authorities. If no authentication process is performed then this forces consumers to gamble with privacy and confidentiality.

With “authentication” consumers can identify the entity with whom they wish to communicate.

With no “entity authentication” ‘n’ is approximately 60,000,000 and growing at 55,000 per day. Enterprises and businesses which force users to gamble private and confidential information will lose out to those whose identity can be established directly from their SSL certificate.

Let’s look at SSL itself in more detail.

What is SSL?

Established by Netscape in 1994, the SSL protocol is now widely accepted as a method of providing confidentiality, authentication and integrity for on-line transactions. Companies such as VeriSign and Comodo deliver high assurance certificates to individuals and organization’s following a subscriber authentication process that includes verification of the organizations existence, the organization’s right to use the domain name included within the certificate and the authority of the requester to obtain a certificate on behalf of the organization.

The original concept from Netscape stated:-

“Third-party CAs are critical for some applications. For example, a bank that wishes to put a server on the Internet for online banking cannot just issue its own certificate to that server and ask customers to believe that it really is the bank’s server. Instead, the bank will purchase a server certificate from a third-party CA. The third-party CA takes responsibility for performing due diligence and ensuring that the company requesting the certificate really is the company it says it is before issuing the certificate.”

The use of SSL certificates is a critical building block for secure electronic commerce and one of the most ubiquitous uses of public key infrastructure (PKI). SSL certificates are “High Assurance” if they provide three security services – confidentiality, authentication and integrity. They enable a user to:

For example, an SSL certificate with the organizational name “ABC Software Inc.” is intended to provide assurance that the Web site being viewed (e.g. www.abcsoftware.com) is actually an ABC Software Inc Web site (and not a “spoofed” site created specifically by another, unrelated entity to trick unsuspecting web surfers into doing business with someone pretending to be ABC Software Inc.)

Why is it important? A domain name URL (uniform resource locator) is equivalent to a telephone number. It is assigned to a paying customer (organization or individual) for the period of time it is registered.

The domain name system was designed to support open-systems information flow. While there are restrictions on certain types of domains (e.g. .mil is restricted to US military entities, .fr is restricted to organizations physically located in France), there are no such restrictions on .com, .org, .net and others. To register for these types of domains the individual or organization need only pay an annual fee. There is no requirement for registrars to verify the accuracy of the information provided.

With multiple browsers available to view the Internet, the importance of providing a consistent assurance mechanism to an Internet population of greater than 1 Billion individuals is paramount. The architecture of leading Internet browsers available from Microsoft, Mozilla Foundation, Opera and others was originally constructed in such a way as to provide assurance through the use of simple icons (in the form of locks and keys).

However, changes in the SSL certificate marketplace have posed a significant security risk with a huge potential threat to consumer confidence in the security of online commerce.

Internet Explorer does not differentiate between high and low assurance certificates. Even more recent browsers like Firefox, although displaying the signatory authority, still require in-depth analysis by the user of the certificate itself.

Due to the practices of Low Assurance certification authorities, the padlock can no longer be assumed to symbolize trust

Browser providers have recognized this. The latest version of the Opera Browser (8.0) now has the ability to display organizational (entity) information directly from the web site’s SSL certificate.

Entity information is available from the SSL certificate.

No Entity information is available – Encryption is of unknown worth and so trust cannot be established.

Authentication of an organization

Providers of low assurance SSL certificates do not perform all the necessary checks, choosing instead to offer a reduced cost, rapid fulfillment model. This is in direct conflict to accepted industry practice and serves as a source of distrust, confusion and fear for internet users. Whereas in the past it was merely acceptable to rely on the lock symbol, users without tools like Opera must now examine and understand the contents of the SSL certificate, in order to distinguish between the varying levels of assurance. In some cases users may need to refer back to the CPS (Certificate Practice Statement) to be able to understand the level of assurance provided. Industry standards for subscriber registration require that a certification authority (CA) maintains controls to provide reasonable assurance that:

A certification authority’s code of practice is detailed in a CPS (Certificate Practice Statement) or disclosed within the CA’s published certificate policy (CP). There are three fundamental verification steps necessary to be able to issue an SSL certificate to an organization:

The importance of the validation steps are identified in the risk table below. In general, an internet user incurs a higher risk if any verification steps are not performed. In each example scenario, the failure to complete the specified checks could expose:

SSLv2 versus SSLv3/TLSv1 and Assurance Level
It’s now widely accepted that SSLv2 was insecure. A critical failing of SSLv2 was its susceptibility to a Man-in-the-Middle attack . With SSLv2, it was not possible to guarantee that you were communicating securely with the owner of the private key.

With SSLv3 and the equivalent TLSv1 you can now be sure that only the owner of the server’s private key can decrypt any information sent. However, as we have already established, where Low Assurance SSL is used, no entity authentication is performed and therefore it is not possible to know who the owner of the private key is. SSLv3.0 is therefore open to a Man-in-the-middle attack with Low Assurance SSL.

With no entity authentication consumers have no ability to know if they are subject to a man-in-the-middle attack.

The Legal implications of using Low Assurance SSL certificates.

The role of a Certification Authority (CA) is to certify that an applicant is a legitimate and legally accountable entity. Consumers are afforded far greater protection with High Assurance SSL certificates in the event of a legal claim they have lines of recourse.

Low Assurance SSL certificates provide no legal recourse, and consumers remain unprotected. The actual implication for the user who relies upon an enterprise or business that purchases a low assurance SSL certificate has not yet been tested through the courts.

What actually is the difference between High Assurance and Low Assurance?

As we have established, High Assurance validation is about “Certifying the end entity” and therefore “authenticating the intended recipient”.

Low assurance processes fail to “authenticate the intended recipient” as discussed earlier in the definition of “encryption”. The only item validated is control of a domain. Domain names are themselves susceptible to vulnerabilities.

DNS cache poisoning is a technique which corrupts the DNS (Domain Name System) injecting false information into the system so that future requests can be diverted from their intended destinations. In a DNS poisoning attack it is possible for a localized domain of the same name to exist, and therefore possible for a second fraudulent Low Assurance SSL to be created. As no other checking is done an attacker can obtain an SSL certificate for any domain name that can be affected by a DNS poisoning attack. Low Assurance SSL certificates are susceptible to DNS cache poisoning attacks.

Low Assurance SSL and compliancy to International Standards

SSL certificates must conform to internationally recognized standards for interoperability and are thus X.509 compliant. The data structure within X.509 itself makes use of another International standard, namely X.520:

5.4 Organizational attribute types

collectiveOrganizationName ATTRIBUTE ::= {
SUBTYPE OF organizationName
COLLECTIVE TRUE
ID id-at-collectiveOrganizationName }

X.509
Information technology – Open systems interconnection – The Directory: Public-key and attribute certificate frameworks
X.520
Information technology – Open Systems Interconnection – The Directory: Selected attribute types

Here the ‘O’ – Organization field does not contain the organization “Better Business Bureau” so consumers have no ability to verify that the certificate actually belongs to that organization.

IS THERE SUCH A THING AS 100% SECURITY?

Is entity authentication the answer to achieve 100% security?

The answer is no, as 100% security does not exist! Any security related process or product is vulnerable! Security is about “risk mitigation”.

Can the validation systems we have in place today be fooled or circumvented? Yes they can, but is this a reason to abolish them? Of course not! It’s rather like saying, because our doors within our homes can be broken, let’s remove them completely! It’s ridiculous to even suggest this. What we need is even more security processes, products and service to secure ourselves. Removing what little protection we have is, irresponsible, short sighted and wrong!

Low Assurance SSL provides little of any value and this is often reflected in its low price.

The organizations offering Low Assurance SSL should immediately increase the level of validation they perform and work to identify better and stronger forms of entity authentication. Certification authorities should raise the bar, not lower the bar.

An entity obtaining a fully validated High Assurance certificate for use in committing fraud would leave an audit trail. Law Enforcement authorities would have more chance to secure a conviction.

IN SUMMARY

An SSL encrypted session between web browser and the web server provides a secure tunnel, but by default does not provide assurance in the identity of the end entity. Whilst a few high assurance providers continue to offer high assurance validation processes, many more low assurance providers are entering the market offering high speed, low value automated validation procedures. These low assurance products are not appropriate for encryption and do not provide either reliable privacy or trust.

Enterprises have a responsibility to ensure that the use of high assurance SSL certificates provides customers with the identity assurance and confidence to make safe, secure on-line transactions.

The goal of ever increasing security should drive future standards with entity authentication an absolute minimum where encryption and trust is required. After all,

What is the point of encryption if you don’t know who for?

i. http://dictionary.reference.com/search?q=encryption, definitions copyright of Houghton Mifflin Company

ii. http://news.netcraft.com/archives/web_server_survey.html

iii. http://wp.netscape.com/certificate/v1.0/evalguide/

iv. http://www.eucybervote.org/Reports/MSI-WP2-D7V1-V1.0-02.htm

v. http://en.wikipedia.org/wiki/DNS_cache_poisoning

vi. http://archive.dante.net/np/ds/osi/9594-6-X.520.A4.ps

Dr. Colin Walter has a formidable international reputation in the design of hardware and algorithms for the implementation of RSA cryptography. He is on the programme committee of several international conferences (e.g. CHES and ARITH) and has given invited lectures on many occasions. He obtained his doctorate in algebraic number theory from Cambridge University and he is a senior member of the IEEE. Colin is most well-known to the international community for his invention of the first ever purely locally connected systolic array for modular multiplication. This enables servers to perform the calculations for very large numbers of SSL key exchanges at once. Recent research has led to the MIST algorithm, patented by Comodo, which is a key ingredient in the secure implementation of electronic purses on smartcards.

With national security a high-priority issue, allowing people to travel with forgeable paper documents will become a thing of the past. Embedded media that can hold multiple photo angles, fingerprints, retinal scans, and anything else the government deems necessary will become part of the typical passport.

According to the International Herald Tribune, the next step will be to sift through the various smart card manufacturers, big and small, to find one that can provide a suitable media and readers for it.

Two types of readers for embedded microchips exist. One type, used for toll collecting on some highways, would be a contactless chip. By passing the microchip near a reader, the reader can collect the information.

One obvious problem could be the potential for remote theft, or skimming, of contactless data. Encryption would have to be part of the security for a contactless solution.

The other type of smart card would be swiped through a reader, like a typical credit card. That removes the risk of skimming, but a bit of wear on the wrong place on a strip could render a swiped passport useless and highly inconvenient.

A contactless passport could be lined with something metal that would protect the chip and foil skimming attempts. Another possibility could be the use of RFID chips, a simpler device than a smart card. But data security would be an issue with RFID, and the potential for skimming still exists.

Whatever solution wins out, it will have to happen soon to suit US policies. Currently, citizens of 30 countries may enter the US without a visa. That situation ends in October, and those citizens will have to use some type of electronically-augmented passport to enter the country.

David Utter is a staff writer for WebProNews covering technology and business. Email him here.

The SHA-1 standard is one of the primary building blocks for most cryptography protocols and is used to create digital signatures. Because of SHA’s unending reach throughout the encryption industry, problems resulting from this hack could be gigantic.

According to Techworld.com,

Virtually all application and server software that incorporates SHA-1 into its functions – including Web browsers, e-mail clients, instant messaging programs, secure shell clients, and file- and disk-encryption software – will need to be replaced or upgraded

For regular computer users, the breaking of SHA-1 has no sudden repercussions. Secure online communications have not been thrown wide open. A tougher standard that hasn’t been broken, called SHA-256, already exists. Encryption experts are urging software companies to integrate SHA-256 into applications that currently use SHA-1.

News of the SHA’s hack surfaced at the RSA conference, an event devoted to securing Internet and other computer technologies.

WebProNews | Breaking eBusiness News
Your source for investigative ebusiness reporting and breaking news.

One way to solve this problem is to encrypt the data before it is written to the external file, then read and decrypt the data before using it in your application. The Java Cryptography Extension (JCE) provides an API that will let you do this.

Symmetric or “single key” encryption is a good choice for solving this type of problem. Single key encryption uses the same key to encrypt and decrypt data. DES and DESede are two single key encryption schemes. I will show you how to solve this problem using either of these encryption schemes with the JCE.

The Problem

You need some way to secure the parameters used by your source code when they are stored in external property or configuration files.

The Solution

Encrypt the data before it goes in; decrypt it before your application uses it.

Encrypting a String

There are two main classes that I have created to solve this problem: StringEncrypter and EncryptionScheme. Figure 1 shows a UML representation of what is provided in the source code.

The StringEncrypter class (Listing 1) provides methods that allow you to encrypt and decrypt a string using a given encryption scheme. The first constructor takes two parameters: an object of type EncryptionScheme and the encryption key that will be used to encrypt and decrypt. After you construct the StringEncrypter, you can encrypt and decrypt a given string using the eponymous methods, encrypt and decrypt.

I have provided a set of unit tests that demonstrate how the StringEncrypter works (see Listing 2).

EncryptionScheme is a Java interface that encapsulates the properties of different encryption schemes. A concrete class that implements the EncryptionScheme interface is passed into the StringEncrypter (this is known as the strategy design pattern). You can pass a custom key into the constructor, or you can use the one that is provided by default, DEFAULT_ENCRYPTION_KEY. If you use the single argument constructor, it will automatically use the default key.

The main calls in the encrypt and decrypt methods are the calls made to the Cipher class (see the next section). The Cipher.init() method takes an integer that represents the encryption mode (encrypt or decrypt) and the key as an argument. Static constants representing the encryption mode are defined on the Cipher class. The Cipher.doFinal() method performs an encryption or decryption, based on what mode was initialized.

The Java Cryptography Extension (JCE)

The EncryptionScheme object that is passed into the constructor of the StringEncrypter class is used to generate three class-level fields: a KeySpec, a SecretKeyFactory, and a Cipher. The encrypt and decrypt methods on the StringEncrypter also use the SecretKey class. These classes are part of the JCE, a framework that provides key generation and encryption, among other things. This package comes standard in J2SE v1.4 and is available as an optional package in Java 2 SDK, versions 1.2.x and 1.3.x.

Here is what the Java 1.4.1 API specification has to say about these classes:

There are two other classes that are used in the enrypt and decrypt methods. The classes are: BASE64Encoder and BASE64Decoder. These classes are not part of the JCE, but they are helpful for converting between byte arrays and strings. BASE64Encoder encodes a binary stream as a “Base64″ format string. BASE64Decoder decodes a “Base64″ format string into a binary stream

Using the StringEncrypter

Along with all the implementation classes shown in the source code download, I have provided a set of unit tests that demonstrate how the StringEncrypter works.

Testing Encryption

public void testEncryptsUsingDesEde() throws Exception
{
&nbsp&nbsp String stringToEncrypt = "test";
&nbsp&nbsp String encryptionKey = "123456789012345678901234567890";

&nbsp&nbsp assertEquals( "Ni2Bih3nCUU=", encryptedString );
}

This test shows how a client application would encrypt a string using the DESede encryption scheme. First, I specified a string that I wanted to encrypt-”test”-and an encryption key. For DESede encryption, the encryption key must be more than 24 characters long. I used a 30-character encryption key just to be on the safe side.
There is no instance-specific data in the DesEdeEncryptionScheme class, thus it is designed using the Singleton design pattern so that you don’t have to maintain multiple instances of the class in memory. The EncryptionScheme object is obtained through a static constant defined on the DesEdeEncryptionScheme class.

Next, a StringEncrypter is constructed using the EncryptionScheme and the key. At this point, obtaining an encrypted string is as simple as calling the encrypt method, and passing in the String you wish to encrypt. The test asserts that the value of the encrypted string is correct according to its previously determined value (a regression test).

Decrypting the string is just as simple. A StringEncrypter is constructed by passing in the encryption key and the EncryptionScheme object. The encrypted string is passed to the decrypt method, which returns the unencrypted string (“test”).

Testing Decryption

public void testDecryptsUsingDesEde() throws Exception
{
&nbsp&nbsp String string = "Ni2Bih3nCUU=";
&nbsp&nbsp String encryptionKey = "123456789012345678901234567890";
&nbsp&nbsp EncryptionScheme encryptionScheme = DesEdeEncryptionScheme.INSTANCE;

&nbsp&nbsp assertEquals( "test", decryptedString );
}

Supporting Other Encryption Schemes
The EncryptionScheme interface allows you to add support for different symmetric encryption schemes. An abstract class called BaseEncryptionScheme is provided, which provides basic functionality for concrete EncryptionScheme classes. This abstract class is an extension tool for adding your own encryption schemes.

The code provided with this solution includes EncryptionScheme implementations for the DES and the DESede encryption schemes. Either of these schemes should suffice for solving the problem outlined in this 10-minute solution. Other symmetric encryption schemes include: HmacSHA1, Blowfish, HmacMD5, and TripleDES.

Making Good Use of String Encryption

So when would you use this wonderful string encryption tool? There are many possible applications.

One possible application, mentioned at the beginning of this solution, is to use the StringEncrypter to encrypt and decrypt sensitive data in a properties file. For example, you may use the java.util.Properties class to read and write a database password from a properties file. To keep the password secure, you may write a separate program that prompts you to enter your password, and then stores it in its encrypted form in the properties file. This might be a simple GUI-based program or even one that runs from the command line. Your main application will then use the same encryption key to decrypt the password before using it to obtain a connection from the database.

Of course, you may store passwords and other sensitive data in places other than properties files. You can implement the same scenario described above using an XML file, an environment variable, a registry location, or even a datasource such as an LDAP server or a database as a storage location for your encrypted data.

Another application would be to encrypt data before and after it is sent across a network. For example, you can encrypt an e-mail message before it is sent and decrypt it after it is received. Or, you could use the StringEncrypter to provide encryption for all transactions in a client/server application, or all messages sent to a messaging queue.

*Originally published at DevX.com

Javid Jamae is the president of Jamae Consulting, a software development and consulting firm that provides business, training, and development services to large and small companies.

Signing a key tells the PGP software (GnuPG in most cases for us Linux heads) that you’ve acknowledged the key is legitimate when verifying the signature. Let’s take a look at the different verification possibilities.

Here’s the mutt[1] header of a PGP signed email, where we’ve never downloaded the key at all:

gpg: Signature made Wed Apr 14 18:59:36 2004 PDT using DSA key ID D5D3BDA6
gpg: Can't check signature: public key not found

Compare to the next one, where we do have a copy of their public key, but have never signed the key:

gpg: Signature made Wed Apr 14 18:59:36 2004 PDT using DSA key ID D5D3BDA6
gpg: Good signature from "John Doe (My First PGP Key) "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: B53F E57B D0C1 F689 FCE2 5623 5B9A A5F8 801E A932

Or this one, where the public key is on our keyring, and the key is signed by us:

gpg: Signature made Wed Apr 14 18:59:36 2004 PDT using DSA key ID D5D3BDA6
gpg: Good signature from "John Doe (My First PGP Key) <jdoe@example.com> "

And, to round things out, one where the key is on our keyring, signed and all, but the signature is invalid (the message was corrupted in transit, most likely)

gpg: Signature made Wed Apr 14 18:59:36 2004 PDT using DSA key ID D5D3BDA6
gpg: BAD signature from "Jon Doe (My First PGP Key) <jdoe@example.com>"

The third example above is what we’d like to see – messages signed by other parties whom we’ve verified, received with a valid signature, assuring us that the message came unaltered from the owner of the PGP key. When you see this success, either the individual sent it and all is well, or their key has been compromised, no other possibilities exist. Naturally, we’re hoping they haven’t been compromised…

Before we sign the key, let’s check out the existing signatures on this key on our keyring:

# Show the key, and all the signatures too
$ gpg -kvv D5D3BDA6
pub 1024D/D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe@example.com>
sig 3 D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe@example.com>
sub 1024g/26F8D783 2003-12-14
sig D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe@example.com>

Yup, the key is just signed by John himself, no one else yet. Now it’s time for us to sign his key, so GnuPG will stop telling us that it’s untrusted, and so we can introduce John to other people:

$ gpg --sign-key jdoe@example.com

John Doe <jdoe@example.com>

How carefully have you verified the key you are about to sign actually belongs to the person named above? If you don’t know what to answer, enter “0″.

(0) I will not answer. (default)
(1) I have not checked at all.
(2) I have done casual checking.
(3) I have done very careful checking.

Your selection?

At this point you get to tell GPG how thorough you were in verifying the key owner’s identity. If you followed the procedures in the previous article, you probably verified their identity by looking at their driver’s license, passport, doing a fingerprint scan and DNA test, etc. In my opinion, if you can’t honestly say #3 above, then you shouldn’t be signing the key at all.[2]

Ok, so, let’s get this finished up:

Are you really sure that you want to sign this key with your key: “Jane Doe (Home Key) <janedoe@example.net>>”

I have checked this key very carefully.

Really sign? yes

You need a passphrase to unlock the secret key for user: “Jane Doe (Home Key) <janedoe@example.net>” 1024-bit DSA key, ID 42851101, created 2004-01-01

Passphrase: (type passphrase)

Note the utter lack of output in the event that you’ve typed the passphrase correctly – good old Unix tradition at work. So, let’s check out the key now and see our new signature on it.

# Show the key, and all the signatures too
$ gpg -kvv D5D3BDA6
pub 1024D/D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe@example.com>
sig 3 D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe@example.com>
sig 3 42851101 2004-04-19 Jane Doe (Home Key) <janedoe@example.net>
sub 1024g/26F8D783 2003-12-14
sig D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe@example.com>

So you can now see that Jane has signed John’s key on 19-Apr-2004 with her key, 0×42851101. At this point it’s a good idea to send the newly signed key back to John, and if he has no objections upload it to the keyservers as well so everyone can benefit from her signature. We covered this previously, but here’s a reminder:

# Send all keys to keyservers
$ gpg --send-keys

# Extract and email him his signed key
$ gpg --export -a 'john doe' > john_keys.asc
$ mutt -a john_keys.asc jdoe@example.com

There are, of course, other ways you can get the keys to owner if you want. For example rather than attaching the key manually as I have above with mutt[3] you could attach the key using esc k from the message creation screen. Incidentally, if someone sends you keys in email, you can import them using ctrl-k in mutt.

So, by this point we have all the important parts of PGP/GPG/GnuPG in our hands. You can create your keys, verify and sign the keys of others, verify and/or encrypt data. Many tools have built in PGP support to save you from working on the command line, which will make work with PGP as seamless as working with your editor.[4]

NOTES:

[1] Greatest email program in the world

[2] There is a second kind of signature, called a local signature. This type of signature won’t be exported to any keyservers, so no one would know you signed their key. This is useful if you want to stop getting “untrusted signature” warnings on keys that you’re fairly sure are legit, but don’t want to have others believe you have actually verified. The PGP key that comes with your Linux distribution would be a good candidate for local signing. To sign locally, you’d use gpg –edit-key and then lsign, but I won’t cover that further.

[3] I simply cannot plug this email client enough…

[4] And, naturally, that editor should be vim.

Brian Hatch is Chief Hacker at href="http://www.onsight.com/">Onsight, Inc and author of
Hacking Linux Exposed
and Building Linux VPNs.
Brian can be reached at brian@hackinglinuxexposed.com.