Interdepartment Center for Research on Security

One a day keeps the hackers away. Read our discussion of the top 25 coding errors in the appsec streetfighter blog http://appsecstreetfighter.com .

------ Johannes B. Ullrich, Ph ...(more)...

Your pet's name is Poochie? You're pwned

Guessing the answer to common password reset questions is far easier than previously thought, according to a new study by computer science researchers.…

(author unknown)12510204381816767954

Let’s talk about End in End-to-End Trust, or, in other words, the Human Being. Focus on the human subject – the beneficiary of technology We’re pretty good at dealing with everything from the digital perimeter through to the protected resources the person wants to access. But the big problem, the very old problem, that we’ve made little progress in solving, is reliably and confidently authenticating the person to the digital perimeter. Let’s keep in mind the kind of attacks on information systems that we see everyday, the vast majority of them are attacking the Human being through some form of impersonation. My thesis would be that we have extraordinary existing technology for securing everything within the digital workflow, but we are unbelievably immature in our current approaches to securely connecting the Human being (the physical world) to the digital world. 99% of protected resources still rely on Username/Password as the means for authentication of a human being. Let’s be clear about this,  Username/Password does not authenticate a human being, it authenticates a directory entry. We can talk about End-to-End trust forever, but until we can effectively manage the identity risk of human beings using Information Systems, the weakest link will continue to be end-user authentication and it will continue to be the primary focus of attacks. The problem with traditional electronic identity credentials Symmetric key cryptography, or shared secrets, is not an inherently weak form of authentication. It just happens that as its currently implemented though Username/Password across heterogeneous, monolithic systems it is wholly inadequate. Human beings are actually outrageously capable cryptographic processors. In fact, when it comes to communication, language, collaboration and knowledge, almost everything we do is rooted in our ability to perform millions of symmetric key cryptographic operations in real-time and, for the most part, sub-consciously. Two quick examples should cement the point. The citrus fruit called orange, when ripe is also the color orange. At a very young age we’re taught to associate specific labels – red, orange, blue, etc., with specific frequencies of light. So the only reason 2 speakers refer to the color of an orange as orange is because we have a socially agreed upon set of key pairs. Language, alphabets, etc., all work the same way. The only reason I don’t know Chinese is because I’ve not learned those specific encryption/decryption algorithms. Another example should cement the cryptographic nature of these relationships. Prior to going to a potentially boring party, I agree with my friend that if one of us says “how about those Red Sox”, we should both immediately initiate an exit strategy. Since we exclusively know the “code”, for all other participants in the conversation it is effectively “cyphertext. Now, if you think about how many of these operations we constantly perform, for instance, as you’re reading this blog, you will get my point. Bottom-line, human beings are naturally really good at cryptography. So why are Username/Passwords so bad? 3 reasons: They are not easy to use. We don’t intuitively think of or recall 8+ character words with 1 upper-case alpha, 1 lower case alpha, one number and one non-alpha numeric. It’s get even harder when we have to change them every 90 days, and they must be different than the last 10 we used, and we’ve got 30 pairs of them to remember. Compromise is hard to detect. They are typically static for long periods of time – like 90 days — and it’s not obvious to the end-user when someone else has compromised them. They are not unique to the subject. Many people could have the same password, so there is nothing that inherently connects a password to an individual user. Now contrast that with our ability to remember and recognize faces. Even though facial recognition is vastly more complicated then remembering an 8 character complex password, it is orders of magnitude easier and more intuitive for us to recognize faces, and this is just one example of many. Any of these things can be used as key material for symmetric crypto systems. For electronic credentials to be effective and efficient there are a few properties they should exhibit: Ease of use. They should be intuitive, leverage capabilities that we already possess and fit in with our lifestyles and work habits. That implies we need more then one. What may be an appropriate electronic credential when we’re authenticating to an ATM in a private vestibule, may not be appropriate when we’re attending a wedding or sitting in a lecture hall. Easy to detect compromise. It should be obvious, in a short amount of time (minutes or hours vs. days or months) when a credential has been compromised. While it’s almost impossible to know someone’s stolen your password, it’s obvious, pretty quickly, when someone’s stolen your Blackberry. They should be unique to you. At least one, and ideally, multiple components of a credential should be unique, ie., only 1 exists and it’s associated with you. That means when compromised it either no longer exists or is no longer associated with you. Now, I’m not suggesting PIV cards and biometric readers for everyone. Quite the opposite, because they are terrible at 1 and only reasonably good at 2 and 3. What I’m suggesting is approaching the whole concept of electronic credentials from a totally different perspective. People should be able to use whatever credential best suits the particular transaction, the physical and social environment in which they find themselves, and the capabilities they have at their immediate disposal.

Focus on the human subject – the beneficiary of technology

We’re pretty good at dealing with everything from the digital perimeter through to the protected resources the person wants to access. But the big problem, the very old problem, that we’ve made little progress in solving, is reliably and confidently authenticating the person to the digital perimeter. Let’s keep in mind the kind of attacks on information systems that we see everyday, the vast majority of them are attacking the human being through some form of impersonation.

My thesis would be that we have extraordinary existing technology for securing everything within the digital workflow, but we are unbelievably immature in our current approaches to securely connecting the human being (the physical world) to the digital world.

99% of protected resources still rely on Username/Password as the means for authentication of a human being. Let’s be clear about this,  Username/Password does not authenticate a human being, it authenticates a directory entry.

We can talk about End-to-End trust forever, but until we can effectively manage the identity risk of human beings using Information Systems, the weakest link will continue to be end-user authentication and it will continue to be the primary focus of attacks.

The problem with traditional electronic identity credentials

Symmetric key cryptography, or shared secrets, is not an inherently weak form of authentication. It just happens that as its currently implemented though Username/Password across heterogeneous, monolithic systems it is wholly inadequate. Human beings are actually outrageously capable cryptographic processors. In fact, when it comes to communication, language, collaboration and knowledge almost everything we do is rooted in our ability to perform millions of symmetric key cryptographic operations in real-time and, for the most part, sub-consciously.

Two quick examples should cement the point. The citrus fruit called orange, when ripe is also the color orange. At a very young age we’re taught to associate specific labels – red, orange, blue, etc with specific frequencies of light. So the only reason 2 speakers refer to the color of an orange as orange is because we have a socially agreed upon set of key pairs. Language, alphabets, etc all work the same way. The only reason I don’t know Chinese is because I’ve not learned those specific encryption/decryption algorithms.

Another example should cement the cryptographic nature of these relationships. Prior to going to a potentially boring party, I agree with my friend that if one of us says “how about those Red Sox”, we should both immediately initiate an exit strategy. Since we exclusively know the “code”, for all other participants in the conversation it is effectively “cyphertext.

Now, if you think about how many of these operations we constantly perform, for instance, as you’re reading this blog, you will get my point. Bottom-line, human beings are naturally really good at cryptography.

So why are Username/Passwords so bad? 3 reasons:

• They are not easy to use. We don’t intuitively think of or recall 8+ character words with 1 upper-case alpha, 1 lower case alpha, one number and one non-alpha numeric. It’s get even harder when we have to change them every 90 days, and they must be different than the last 10 we used, and we’ve got 30 pairs of them to remember.
• Compromise is hard to detect. They are typically static for long periods of time – like 90 days — and it’s not obvious to the end-user when someone else has compromised them.
• They are not unique to the subject. Many people could have the same password, so there is nothing that inherently connects a password to an individual user.

Now contrast that with our ability to remember and recognize faces. Even though facial recognition is vastly more complicated then remembering an 8 character complex password, it is orders of magnitude easier and more intuitive for us to recognize faces, and this is just one example of many. Any of these things can be used as key material for symmetric crypto systems.

For electronic credentials to be effective and efficient there are a few properties they should exhibit:

• Ease of use. They should be intuitive, leverage capabilities that we already possess and fit in with our lifestyles and work habits. That implies we need more then one. What may be an appropriate electronic credential when we’re authenticating to an ATM in a private vestibule, may not be appropriate when we’re attending a wedding or sitting in a lecture hall.
• Easy to detect compromise. It should be obvious, in a short amount of time (minutes or hours vs. days or months) when a credential has been compromised. While it’s almost impossible to know someone’s stolen your password, it’s obvious, pretty quickly, when someone’s stolen your Blackberry.
• They should be unique to you. At least one, and ideally, multiple components of a credential should be unique, ie., only 1 exists and it’s associated with you. That means when compromised it either no longer exists or is no longer associated with you.

Now, I’m not suggesting PIV cards and biometric readers for everyone. Quite the opposite, because they are terrible at 1 and only reasonably good at 2 and 3. What I’m suggesting is approaching the whole concept of electronic credentials from a totally different perspective.

People should be able to use whatever credential best suits the particular transaction, the physical and social environment in which they find themselves, and the capabilities they have at their immediate disposal. Part II of the post will be coming soon.

Cryptographer, Taher Elgamal of Axway Inc., the inventor and initial driving force behind SSL, explains how applications may be better adapted to defend against attacks.Robert Westervelt06202448387744872480

Yesterday Microsoft re-released KB973811 ==http://www.microsoft ...(more)...

Theres been a lot of discussion about the recent stories on parsing firewall logs - Mar ...(more)...

My appearance on OWASP Podcast 61 is available.

The .mp3 is 36 MB. Thanks to Jim Manico for inviting me to participate.

We recorded the podcast in late January. Jim asked me the following questions:

1. Would you care to tell us how did you get into IT and what lead you into a career in information security? What keeps you busy these days?
   
2. What's the difference between focusing on threats vs focusing on vulnerabilities?
   
3. What is your problem with the "protect the data" mindset?
   
4. What do you mean by "building visibility in"?
   
5. What is your take on the Aurora/Google hack?
   
6. You just tweeted that "Network Security Monitoring ideology is the proper mechanism to combat APT/APA". Do you think network IPS/IDS/WAF can help defend insecure web applications? What are the limits of Network Security Monitoring?
   
7. How important a role do you think secure coding and secure software development life-cycle play in defending the enterprise?
   
8. Have HIPAA, PCI, SOX and other regulations helped reduce risk in the average enterprise?
   
9. Is seems pretty clear that attackers have a clear advantage. Why is that? How can we turn the tide?
   
10. Any thoughts on OWASP? Are we helping the cause?
    
11. Where are we going to be as an industry in 10 years?
    
12. You blogged that "The trustworthiness of a digital asset is limited by the owner's capability to detect incidents compromising the integrity of that asset." Given that we don't have any high integrity database, identities or application servers - how do you detect a breach of integrity when there is no verifiable integrity in the system in the first place?
    

Copyright 2003-2009 Richard Bejtlich and TaoSecurity (taosecurity.blogspot.com and www.taosecurity.com)

I just saw Sergey Bratus’s talk at TROOPERS 10. He’s an interesting guy, and his talk was good. He’s a CS professor at Dartmouth, and he’s actually making an effort, on behalf of the academic community, to inject some genuine security clue into the education of CS students. He obviously has a tough topic to address, but he looks like he’s on the right track to me.

One thing he pointed out is that a lot of vulnerabilities over the years have actually resulted from the accidental creation of Turing-complete systems. (He has a nice Cthulu slide making the point.)

It struck me that one goal of “secure programming” would be the avoidance of the creation of Turing-complete systems. It’s a crazy world when it’s harder to avoid the creation of such a system than it is to actually create one.

Anyway, Marsh and I are speaking in a couple of hours. If you’re here, come by and bring your rotten tomatoes!

As most of the readers on my blog would be knowing, the Security experts in February launched a new effort to ensure software is written from the ground up with security in mind -- a philosophy and message they're aiming at people outside of the security industry.

The Rugged Software Development initiative is basically a foundation for creating resilient software that can stand up to attackers while performing its business or other functions.

"It's more of "a value system" for writing secure software, versus a compliance program, according to its founders,who hope to incorporate the tenets of rugged code development into computer science programs at universities."

A couple of years back, I remember posting a blog article, if basic security mantras could be incorporated in the Computer Science & IT Courses in Universities. Here is the link to the same: http://smartsecurity.blogspot.com/2008/04/can-security-be-incorporated-in.html . I was happy that to learn that 'Rugged' did have this as a part of its initiative. Question is, "When will Indian Universities understand and incorporate the same?" The Indian IT industry spends so much on training costs, as more than 70% of fresh graduates are not employable/productive right away.

This isn't the first industry effort to push developers to bake security into their code. There have been several before like: Homeland Security's Build Security In guidelines, Microsoft's Software Development Lifecycle (SDLC) framework and tools, Building Security In Maturity Model (BSIMM), where financial services firms are comparing notes and sharing their secure coding strategies and experiences and OpenSAMM (Software Assurance Maturity Model), an open-source model aimed at becoming an industry standard for secure software development.

Rugged doesn't include any new frameworks for secure coding, however, and instead will serve as an "on-ramp" for secure software development, Rugged is different because it's aimed at people outside of the security realm. Rugged is specifically targeted at people out of the security context.

Getting the secure software development message to the masses won't be easy, and the plan is to get some initial support and momentum from the application security industry.

Unfortunately, most developers don't know what it means to write secure code, and worse they think they already write secure code if they write high quality code. Software security practitioners have struggled to get past this mindset.

Rugged code is a way of breaking through and instilling a mindset that secure code should be a pride-of-ownership issue just as much as elegant, high performing, and high quality code is.

There has been plenty of buzz about URL shorteners and security. URL shorteners have been described as a new attack vector since being popularized by social networks such as Twitter. I don't feel that URL shorteners are any more of a threat than their full length counterparts and here's why...

How URL shorteners work

The purpose of a URL shortener is to replace a log URL (e.g: http://www.zscaler.com/downloadwhitepaper_stateofweb-q4-2009.html) with a shorter one (e.g: http://bit.ly/cikl0z). When a user clicks on http://bit.ly/cikl0z, he is redirected to http://www.zscaler.com/downloadwhitepaper_stateofweb-q4-2009.html via an HTTP 301 redirection:

GET /cikl0z HTTP/1.1
Host: bit.ly

HTTP/1.1 301 Moved
Location: http://www.zscaler.com/downloadwhitepaper_stateofweb-q4-2009.html
----------------------------------------------------------
GET /downloadwhitepaper_stateofweb-q4-2009.html HTTP/1.1
Host: www.zscaler.com

HTTP/1.1 200 OKThe browser made two requests: one to http://bit.ly/cikl0 and one to http://www.zscaler.com/downloadwhitepaper_stateofweb-q4-2009.html


Existing defense mechanisms

All the existing in-browser (Google Safe Browsing in Firefox, Opera's Fraud Protection, etc.) or external (IDS, proxy, etc.) URL scanners are applied on both the initial short and redirected long URL requests. If the long URL is a known malicious site, it will be stopped whether or not the the user clicks directly on the long URL, or on a shortened URL.

Firefox Safe Google Browsing warning on a URL after a redirection
Also, content inspection (Antivirus, Deep Packet inspection, etc.) is applied on both requests.

The use of URL shorteners and redirections does not require any new security inspection. All of the web browser security tools in place prior to the use of URL shorteners are still relevant.
Hiding the real URL

The main argument against URL shortening services is that users don't know which domain they are being redirected to. In our previous example, users see the bit.ly host name in the link address, and do not know that they will be redirected to www.zscaler.com until after they click on the link. After the redirection, the ultimate destination URL can be seen in the web browser address bar.
The long URL is displayed in the browser address bar after redirection
How many people know the difference between a good URL and a bad URL? Even then, how can anyone be sure that a site won't serve malicious content. Many perfectly legitimate websites (Redcross, Indian Governmental websites, etc.) have been hacked and can contain an infamous hidden iframe to spread malware. Well-known websites are no longer necessarily safer than unknown or new sites. Simply using the reputation of the hostname for deciding whether a URL is safe or not is not a good idea.
In a post Michael wrote a year ago, he checked 100,000 TinyURL (URL shortener service) urls. He did not find any link to a malicious executable, no phishing sites, and really few redirections to malicious content.

I believe the danger of URL shorteners has been overblown, mainly based on the idea that individuals are in a position to determine if a website is dangerous or not simply by looking at the final URL. Users are far better off relying on antivirus, URL blacklists and regular browser updates for security. And these tools work just fine or shortened URLs as well.
- Julien

Several readers have pointed us towards this advisory. This Microsoft advisory outlines a vuln ...(more)...

Overview of theMarch 2010 MicrosoftPatchesand their status. ...(more)...

Security budgets are often based on combination of last year's spending, this year's threat du jour(s), and "best" practices, i.e. what everyone else is doing. None of these help to address the main goal of information security which is to protect the assets of the business. The normal security budgeting process results in overspending (as a percentage) on network security, because that's how the budget grew organically starting from the 90s. 

A simple three step process to achieving a Security Budget that maps to business reality rather than security silver bullet fantasies is as follows:

Step 1. Gather the relevant data for where the enterprise is investing its dollars in IT. Let's assume our company is Jones Widgets.

Step 2. Apply a "flat tax" for security budgeting, for this example let's say 7%, so if Jones Widgets invests $5M in its Customer relationship systems, $2M in Order Management, and $1M in ERP, this is the starting point for assigning priorities on security budgets. This is the part that security people miss, you don't need to do asset valuation - there is a whole group of people in the business that have already done that for you. Your job is to enable the intent that they have already clearly communicated in budget decisions. 

So applying the flat tax, our Jones Widget's budget look like this

IT System IT Budget Initial InfoSec Budget Customer Systems $5M $350k Order management     $2M $140k ERP $1M $70k

Notice that the starting point in this step is aligning the budget with overall Enterprise IT spending. Its not based on whatever area that infosec happened to invest in last year, or what someone at a conference said, its about starting by aligning with what your business values. Its not about security foo-fa-ra, its about Jones Widgets.

Step 3. Efficacy. Let's assume that the Customer Management and ERP systems are behemoth packages that are purchased third party apps, and the Order management system is built in house so you have the source code. The way that you choose to deliver security to third party purchased systems versus the ones where you design, build, and deploy the code will vary. So the next step after initially rationalizing the budget is to assess what's the most effective security I can get for each area. 

Its not that the business budget should trump the infosec budget, but its a very useful starting point. Moving off of those priorities should require a statement of efficacy that some security dollars are better spent in say the Order Management system, because the company controls the code. So if Jones Widgets' Order Management system is built in house, and the business relies on that to process orders, if that Order Management asset is compromised then its not like Jones Widgets can go and buy another Order system off the shelf from a vendor. Its their core business, their DNA.

So let's assume that Jones Widgets wants to scan its code, invest time in threat modeling and so on for its core business asset. This results in pulling 20% in from the ERP and Customer systems

IT System IT Budget Updated InfoSec Budget Customer Systems $5M $280k Order management     $2M $224k ERP $1M $56k

There's no need to get wrapped around the axle on asset valuation, the business gives you a starting point, use it. Then only move away from that when you can make a concrete case on improving efficacy by altering priorities. Or put another way - its your job. Do it.

A new version of the Samurai WTF (Web Testing Framework) distribution, version 0.8, has been r ...(more)...

Learning about security means understanding types of risk, and investors, specifically value investors, have a long demonstrated track record of framing ways to think about asset protection and making it actionable. Recently I've been reading James Montier, very impressed with his approach which is based on a pretty rigid process and objective checklists, here is an excerpt from a recent interview:

Miguel: Let’s talk about the concept of seductive details…can you give us an example of how investors are trapped by irrelevant information?

James Montier: The sheer amount of irrelevant information faced by investors is truly staggering. Today we find ourselves captives of the information age, anything you could possibly need to know seems to appear at the touch of keypad. However, rarely, if ever, do we stop and ask ourselves exactly what we need to know in order to make a good decision.

Seductive details are the kind of information that seems important, but really isn’t. Let me give you an example. Today investors are surrounded by analysts who are experts in their fields. I once worked with an IT analyst who could take a PC apart in front of you, and tell you what every little bit did, fascinating stuff to be sure, but did it help make better investment decisions, clearly not. Did the analyst know anything at all about valuing a company or a stock, I’m afraid not. Yet he was immensely popular because he provided seductive details.

In the infosec world the "seductive details" are threats, hollywood movie plots and the like that infosec people use to get funding. Meanwhile the real structural problems of the core assets (apps, data, identity) remain unaddressed whilst the security world chases the taillights of the latest threat du jour.

Miguel: Interestingly you connect the dangers of irrelevant information to modern risk management. I’m referring to your comments on Value at Risk – “VAR is fundamentally flawed after all it cuts off the very it of the distribution that we are interested in: the tails! This is akin to buying a car with an airbag that is guaranteed to work unless you have a crash…” Can you tell us more?

James Montier: Sure. Modern risk management is a farce; it is pseudoscience of the worst kind. The idea that the risk of an investment, or indeed, a portfolio of investments can be reduced to a single number is utter madness. In essence, the problem with risk management is that is assumes that volatility equals risk. Nothing could be further from the truth. Volatility creates opportunity. For instance, was the stock market more risky in 2007 or 2009? According to views of risk managers, 2007 was the less risky year, it had low volatility, which they happily fed into their risk models and concluded (falsely) that the world was a safe place to take risk. In contrast, these very same risk managers were staying that the world was exceptionally risky in 2009, and that one should be cutting back on risk. This is, of course, the complete opposite to what one should have been doing. In 2007, the evidence of a housing/credit bubble was plain to see, this suggested risk, valuations were high, it was time to scale back exposure. In 2009, bargains abounded, this was the perfect time to take ‘risk’ on, not to run away. Risk managers are the sorts of fellows that lend out umbrellas on fine days, and ask for them back when it starts to rain.

The airbag that's guaranteed to work unless you get in accident is of course the network firewall, which "protects" your system until someone tries to attack it.

For some strange reason, infosec is far removed from business realities. The layers of seductive details about threats create an artificial separation between what infosec spends its money and time on versus what the business invests its money and time in.

By itself this misalignment would be a medium sized problem (there's plenty of wasteful IT spending, and infosec's penchant for overallocating on network toys is just another example). But what makes this a much larger problem is the lack efficacy of protection and detection mechanisms that only work so long as they are not attacked. The reason for this is that security architecture is removed from the core business assets (apps, data, identity) they are supposed to be protecting. Instead the protection and detection mechanisms must form fit to that which they are supposed to be protecting. The reasons air bags work is that they are very close to the asset they are protecting.

Panda Security has a post up on one of their employees buying a brand new Android phone from Vodafon ...(more)...

We received several emails today about the US-CERTanalysis of Trojan horse software found in a ...(more)...

Shared by dre
This is probably the coolest article I've seen in years (author unknown)06202448387744872480

One of the most popular requests we've had is to provide a way to view encrypted traffic. The new Decryption expert aims to solve this problem for TLS/SSL traffic.

Using the Decryption Expert

The purpose of encrypting data in the first place is to hide private information from a third party who has intercepted your network traffic. At first the ability to decrypt this traffic might seem like a violation of this tenant. However, in order to decrypt the traffic you will need to acquire the certificate which contains the private server key. So you can't use this to decrypt just any traffic; you'll need the private key.

After downloading and installing the expert form CodePlex, you will see an option "NmDecrypt" from the expert menu next time you open a saved trace. Next, narrow down the traffic to the TCP conversation you want to decrypt. You can do this with a filter on the TCP port or by choosing the conversation in the tree. If you have already found an encrypted frame, you can use the Find Conversation feature to locate the conversation for you.

Now, run the expert form the main menu or right click the frame. Once you open the Expert you will be presented with a dialog so that you can enter the certificate, password, target output capture file, and optionally a log file. The capture file source will automatically be filled in for you.

Once you are done entering the information hit Start and the expert will attempt to decrypt the selected conversation. If an error is reported, you can provide a log file name to get more detailed information to which can help understand why you the decryption failed.

Viewing the Resulting Trace

When NmDecrypt completes, the resulting trace is automatically opened. One advantage of creating a new capture file is that you can send it to another user. This means the owner of the private key can decrypt the file without having to exchange the key.

The resulting trace will contain all of the original information plus new frames with a protocol header called DecryptedPayloadHeader. Thus you can find all inserted packets by applying this protocol as a filter. Of course you can also create a color filter as well if you want to easily identify them among the encrypted and inserted defragmented frames.

The Decryption expert will also insert fragmented frames, which can for the most part be ignored. These frames are created in the first pass for the expert and provide some level of transparency if you need to troubleshoot this transformation.

Finally, there may be some cases where multiple SSL messages are combined in one frame. In these cases the expert won't split them into multiple frames. While this might be possible to do, we'll leave it as an exercise for the open source community.

NmDecrypt Documentation

The documentation contains more information about using the expert, such as the encryption algorithms that are supported and typical errors you might encounter. You can access the documentation through the expert menu. We also describe how to extract the certificate for Windows machines in the appendix.

NmDecrypt is Open Source

The best part of all of this is that we've released the expert and all the source code on CodePlex. We encourage you to extend and improve this expert. In fact there are known deficiencies, (some might call them bugs :) ), that you could help to resolve. These have been listed on the issues tab in the CodePlex project. Plus there's no reason this same technique could not be extended for other encryption schemes. More info on developing your own experts is available at on our CodePlex Expert Site and feel free to view our new expert integration video on channel 9. Please download and give the expert a try and enjoy!

PaulELong0694750750522852757106202448387744872480