Slashdot Mirror

Interesting. Have you seen many such apps? Could you tell me which app it was?

Here's one real example for you: Entrust Truepass, which is an enterprise platform which allegedly makes internet transactions super secure. It's a POS. The user has to run java in their web browser for it to work.

When java 1.6u29 came out, all Entrust Truepass applications stopped dead. Unfortunately, Entrust Truepass has spread to many websites, including:

Government of Canada:
http://www.tpsgc-pwgsc.gc.ca/gji-icm/01/20111020-eng.html

Lowes purchasing with vendors:
http://www.loweslink.com/pubdocuments/How_to_resolve_Java_6_update_29_issue.pdf

US Patent Office:
http://tacticalip.com/2011/11/11/the-patent-office-is-not-ready-for-the-java-update/

And many others, including some banks. The only solutions were:

- run an old version of java with well documented easy-to-exploit security holes while carrying out important transactions
- don't use Entrust Truepass

Given that Entrust Truepass is marketed to businesses interested in security, neither option is acceptable.

Eventually Entrust Truepass fixed their java crapplets, but you really should move to a normal web app that doesn't depend on java.

Entrust Truepass is a real POS.

It's a java applet that some paranoid websites like to use. They claim "zero footprint" which is an outright lie. It only works with a handful of java JREs, and a few web browsers.

The only reason anyone buys it is that it's the only java applet with FIPS 140-1 certification, so if you need to tick that box on your checklist, and you like java, you're stuck with it.

Unfortunately I know Entrust Truepass well since my company's bank, Scotiabank (a major bank in Canada) requires Entrust Truepass for online business banking. Not only that, they require IE 5.5 or IE6 because this crappy java applet doesn't work well with firefox, chrome or safari.

And Entrust Truepass doesn't work with web proxies.

All the legacy IE6 users I've met tend to be government, non-technical corporates or extremely pro-Microsoft shops that bet the farm on IE6 and wrote everything in IE6/ActiveX fashion.

Ha. My company's bank website for business clients is a POS written with a crappy java app called TruePass from Entrust.

It is piece of crap that requires IE6 or IE5.5, and won't work with web proxies.

The bank is Scotiabank, the 3rd largest bank in Canada (and bigger than Citibank & US Bancorp). This is only the case for their business clients - they are forced to use the "Scotiaconnect" service. They even have a helpful browser detection webpage telling you how crappy their website is and requires ancient versions of IE.

Scotiabank's individual clients have a normal html-based website.

Depends on who is making them.

http://www.entrust.com/strong-authentication/identityguard/calculator.cfm

Entrust here likes to advertise they're 1/7th as expensive as the ones RSA sells, and those are still $4/year.

So at $6 until the token dies, Blizzard isn't exactly making a mint on these things. The profit for them comes in reduced account restorations.

Unless you'd care to source me someone who sells them so cheap that Blizzard is making a fortune at these prices, since there's probably also costs for the server end of the setup?

If someone later comes along and claims they created the content, they will have to prove they created it before you had it signed.

Yet, another possibility is to post a lower quality version of a picture and keep the high-resolution version for cases like this. Or to crop the edges so you can prove you have the original and the person claiming copyright does not.

It doesn't seem to work anyway. If go to entrust.com using IE7 the address bar stays white. Has anyone seen it turn green?

Try this:

• Go to Entrust.
• Click on "Login".

This company is notorious for overpaid CEOs while their people don't get raises for several years. They finally got one this year; enough to buy a case of beer ($30) every two weeks. While the CEO makes over $1,000,000 and gives himself bonuses. This is noticable enough that he has even been asked in interviews about it.

Disclaimer: I used to work for Entrust but decided to get back into IT Consulting (I found supporting the same PKI day in and day out does get a bit dull after a while) but I thought I should give them a little plug

What will drive this will be developing and promoting a decent public PKI system. "Stop by the Customer Service Counter with enough ID and someone (with a bit of training) will certify you for a "Trusted Customer Card & Code" today!"
It already exists, well in Canada anyways.
The Government of Canada's epass system (http://www.entrust.com/government/goc.htm) uses Entrust's Self Authentication Server and TruePass to create a secure web site where the user gets a certificate to do specific tasks online that they would normally need to call or visit an office. Mind you they can't use it for anything else than the GoC's website as nothing gets dropped to the user's computer but really that wouldn't be hard to do and have the user store it in their CAPI store so CAPI aware applications (i.e Outlook) could use it or even export to a PKCS#12 file that they could import into Thunderbird.

Roll out a free plugin for the top 5 email clients and the lead will be impressive. It's techie, it's "smart", it'll be like recycling without having to deal with material objects.

I was trying to push for some kind of plug-in for Thunderbird for at least Windows when I was there but alas not enough customer demand. :( However most modern PKI will export the user's cert to a PKCS#12 or PKCS#7 file which could be imported into a third-party app or directly into the CAPI store for MS Windows. The Plug-ins just make it easier. As well for Entrust with EMS 8 and WebMail Center (which are both based off of linux using TomCat as an interface) the recipient doesn't necessarily need to have a cert.

Essentially what happens is the sender emails but since he doesn't have the user's cert it gets forwarded (encrypted for the EMS server) to the EMS Server. The EMS server will then send an email to the final recipient requesting to harvest their cert by replying to the email sent with a signed copy. Once the EMS server gets back the signed email, it will use the attached public certs to encrypt for the final recipient. With WebMail center what occurs is that in the email the EMS server sent, there would be a URL which the recipient would go to using SSL. At that URL, a mailbox will have been created that the recipient would be able to use to read their email as well as respond.

It was nifty to use and interesting to work there but I decided I wanted to do other things in my life besides PKI.

My information got compromised twice. The first incident was with eCheck (used at the time by Scottrade), which got hacked into. The other incident was with Colorado Technical University, in which an employee inadvertently mailed out an attachment with a roster of students. This roster included my whole life basically. Perhaps until there is some general law of accountability e.g. SOX, GLBA, or HIPAA companies and institutions will take protecting information more seriously? Perhaps when the cost of security is less than the legal suits that will follow the incident, they will be more proactive? The hacking incident might have been more difficult to guard against, but the email incident could have easily been prevented with something like Entrust.

I work with a company called Entrust and we have a competitive product to RSA's SecurID that suits the criteria you've outlined above that you may be interested in looking into. Entrust IdentityGuard is a comprehensive strong authentication platform for Internet and enterprise applications. This suite of strong authentication capabilities enables your organization to take a risk-based approach to tailoring your security deployment. The flexible deployment options enable you to match strong authentication methods to the level of risk associated with the different types of users, transactions, and applications of your unique environment. Feel free to contact me if you are interested in more information. You can also visit our website at http://www.entrust.com/identityguard/index.htm for more details.

Entrust IdentityGuard is a cool solution (IMHO) for this type of two-factor authentication. "Bingo Cards" for banking!

Yea you can get this kind of thing off the shelf

To be honest, I have no idea. It isn't the product I support and there is enough to know about the products I do support that there isn't time to learn too much of the other products. You would be best off contacting the sales team (or wait until Monday and I can discretely ask).

They are doing a marketing campaign right now called TokenRevolt that is supposed to be pushing Identityguard. Even RSA has mentioned it I guess although they thought it was a little cheesy but I think they kind of missed the point in the "amateurish" feel it was supposed to have.
www.tokenrevolt.com

From what I have heard, we have quite a few companies and organisations that have a keen interest in this product nowadays just because of the fact there aren't any batteries needed and the much lower cost than a hardware device.

Oh if interested more in the stuff I do support:
Compliance Server
WebMail Center
Messaging Server

To be honest, I have no idea. It isn't the product I support and there is enough to know about the products I do support that there isn't time to learn too much of the other products. You would be best off contacting the sales team (or wait until Monday and I can discretely ask).

They are doing a marketing campaign right now called TokenRevolt that is supposed to be pushing Identityguard. Even RSA has mentioned it I guess although they thought it was a little cheesy but I think they kind of missed the point in the "amateurish" feel it was supposed to have.
www.tokenrevolt.com

From what I have heard, we have quite a few companies and organisations that have a keen interest in this product nowadays just because of the fact there aren't any batteries needed and the much lower cost than a hardware device.

Oh if interested more in the stuff I do support:
Compliance Server
WebMail Center
Messaging Server

To be honest, I have no idea. It isn't the product I support and there is enough to know about the products I do support that there isn't time to learn too much of the other products. You would be best off contacting the sales team (or wait until Monday and I can discretely ask).

They are doing a marketing campaign right now called TokenRevolt that is supposed to be pushing Identityguard. Even RSA has mentioned it I guess although they thought it was a little cheesy but I think they kind of missed the point in the "amateurish" feel it was supposed to have.
www.tokenrevolt.com

From what I have heard, we have quite a few companies and organisations that have a keen interest in this product nowadays just because of the fact there aren't any batteries needed and the much lower cost than a hardware device.

Oh if interested more in the stuff I do support:
Compliance Server
WebMail Center
Messaging Server

Disclaimer: I work for them (for another 2 weeks)
http://www.entrust.com/identityguard/index.htm
1 credit card sized sheet is a lot easier to carry and a lot cheaper to produce than some hardware.

http://www.entrust.com/identityguard/index.htm

But I do like the button feature

So saying "I'd use ECC because it's faster" is a tad loaded.

Besides RSA Security, other companies analysts lump into Certicom's peer group include Symantec Corp, Check Point Software, VeriSign Inc., Gemplus Interntional, SafeNet Inc., Netegrity Inc. and Entrust Inc. However, none of them work directly with patented ECC-related technology.

A much smaller 224-bit ECC key offers the same level of encryption as 2048-bit key in the competing RSA format. In other words, a company would need 16 times stronger encryption to get the same level of protection that Certicom offers in the ECC format.

How is this different from server systems currently offered from the likes of companies such as RSA and Entrust?

They are shifting the complexity from the client to the server, which is good. But it has been done before.

They claim that it'll also work on Netscape 6, so it's not ActiveX. If it turns out to be Java, then it should work on other OSes as well.
One example is Entrust TruePass, which uses a Java applet as the client end of a web-based public key authentication system. It works just fine in Mozilla on Linux.

It looks like there is some information here

it doesn't look like they're offering an RA or subordinate CA, unfortunately.

You didn't look hard enough. The RA comes bundled with the CA (Oops I mean Security Manager). The CA can be configured to be a subordinate with little trouble during installation.

I used to work there, and there's a fairly good reason international prices are much higher.

Entrust is a company headquartered in the US but with the bulk of the workforce in the US. When applying for an SSL certificate, there's a very stringent set of rules set out by both US and Canadian governments that they have to follow in order to verify that the person requesting the certificate in fact represents the organization he/she claims to, and that the request for a certificate was authorized.

Verification requires three independent contacts within the requesting organization. These can be managers, sysadmins, billing, etc. All three need to be contacted.

Calling these contacts up can get expensive when you handle a lot of international orders. International information like addresses can also be difficult to verify halfway around the world, too, adding more costs. This is partly why Canadian prices scale up with the US exchange rate, but international ones are so much higher.

The OTHER reason it's a bit higher is that Entrust doesn't WANT to have to handle international verifications, preferring to pass that on to their affiliates located around the world. This way, customers place the order through the affiliated site (at a price that's supposed to be a fair bit lower than the international pricing Entrust itself offers), the affiliate handles the verification themselves. Since affiliates are located in the same geographic area as their customers, they're better qualified to judge whether the info is correct or not. Once the affiliate has verified the information Entrust issues the certificate.

So if you're not based in the US or Canada, check the list of affiliates to see if there's an affiliate in your country that offers lower "international" pricing. Don't mean to sound like a sales agent, but that's why affiliates are there.

They're popular in europe, too. I see they're partnering with Sun, but it doesn't look like they're offering an RA or subordinate CA, unfortunately.

I just checked them out. Decent prices. Their prices are here for those who are interested.

a bunch of excellent geeks I know use entrust.

Security should be layered:

So once you've made it hard for the hacker to get into the system, also make it pointless. If the data that resides on the system is also strongly encrypted, than obtaining valuable information is not only hard it is a collossal pain, and beyond the capability of anyone except maybe NIST. BTW SSL as implemented by Web servers and browsers can't maintain encryption of data through to the back end, you need a third party product for that ( Yes they exist ).

Indeed. borwser implementation of SSL is pretty broken, but since the credit card companies are mostly limiting the card holders liability, it doesn't much matter to the average joe. For secure email, however PKI implementations are (or at least can be) much tighter. The initial outlay to run your own Ceritifcate Authority is expensive however, so this is best suited to large coms/orgs/govs.
Three companies that sell these systems are:
Entrust Inc.
RSA
Baltimore Technologies

This is no longer the case. Microsoft has changed their policy on this for the time being. CAs pay nothing...

On the other hand, CAs must pass a WebTrust CA audit in order to get on the list. WebTrust audits are extremely expensive. Of course, they serve a useful purpose. They serve to give the end user some sense of confidence that the CA does due dilligence in determining that "you are who you say you are" before issuing a certificate. There is a very small group of companies that have passed WebTrust Audits... (according to WebTrust press releases, Verisign, Entrust, Digital Signature Trust).

Setting up a non-profit to issue certs sounds like a nice idea, but isn't a realistic option when one must spend lots of money to audit ones practices to assure the public. The commercial CAs are even having troubles making money...

Determining that "I am who I claim to be" really is a difficult task.

All PKI does not suffer from this. All poorly implemented PKI does. Microsoft is in a very difficult situation here, and this is why:

Verisign issued a certificate containing the Microsoft name, which it should not have. Most likely this is human error. This kind of thing happens all the time, from the inocuous (name misspelled) to the not-so-good (name of summer intern happens to be the same as the CEO). PKI has revocation options, including certificate revocation lists (CRLs) and online certificate status protocol (OCSP) to handle the case in which you want to stop trusting a certificate that you issued.

So, Verisign issues the certificate, realizes that the dude doesn't work for Microsoft, and then revokes the certificate and calls Microsoft. Verisign has done their duty here, and although they get some of the blame for the initial certification, they have issued a revocation list containing these certificates. Verisign has now done its job.

Unfortunately, Microsoft has crappy PKI capabilities in their products. It wasn't until Internet Explorer 5 that they could handle CRLs at all, and that's only in the case where the CRL is available over the web (HTTP:) and the certificate contains a pointer to its CRL (called a CRL distribution point or CDP).

So, Microsoft's difficult situation is that they must now patch the client software on EVERY Microsoft client that uses Microsoft Crypto API (including IE, Office, and Win2K to name a few) in order to add this new CRL and be able to check it. If their PKI was able to check an OCSP responder at Verisign, or always knew that they could get Verisign CRLs from ldap://ldap.verisign.com, they wouldn't have to issue this press release and a patch at all.

--Peter

DISCLOSURE: I work for Entrust Technologies, a company which makes PKI software that does not suck.

According to this http://www.neteconomie.fr/news/infoCOM.php3?id=838 (in french can't find anything in english, sorry), MP3Pro shouldn't be the only new codec blooming in spring 2001. Universal Musics wants to launch his new codec: BlueMatter (developped by Entrust (http://www.entrust.com/?).

According to this interview (once again, in french sorry) of the director of Universal Music France, BlueMatter should be used to make people pay for online music (I also read about Universal projects of online music and it seems to be streaming only).

So I guess that the new formats won't be as public as MP3 has been to prevent unauthorized players and encoders. One can always try to revers enginer the codec but it'll be hard both technically and legaly (especially in USA with the DCMA if they intermix an access control process with the codec). Beside, this was the strategy used by Apple with the Sorenson codec and unfortunatly there is still no free (as speech) Sorenson codec.

Did you look at Entrust? They sell products that do just that.

---

The people who make decisions on important things like this don't know enough about what's going on. Judges make laws that are completely stoooooopid because they think the laws of the real world still hold relevance on the internet. Many people believe that if a cipher has been around for 5-10 years without any major attacks, it's safe. This isn't true. If you look at the AES finalists, they all employ 3 fundamental properties: a) input/output XORing b) a linear operation in each round c) a differential operation (S-box) in each round Because of the 3 biggest attacks on ciphers: 1) key recovery (basically knowing the input and output to the first and last rounds without even knowing the key is not good, so we XOR the input and output) 2) linear cryptoanalysis (guess what kinds of operations this is useful against? :) ) 3) differential cryptoanalysis (guess what kinds of operations this is useful against? :) ) Many of the ciphers used in BSD/Linux aren't using this for two reasons: 1) Script Kiddies can't write the code to attack these ciphers nor employ the HW horsepower to do it. 2) The AES is coming. When the standard is announced (not barred IP problems overseas), you can bet freahmeat and replay will have C/ASM/Java source code for many platforms. I hope this answers a lot of your questions. BlowFish (or even flipping the bits of you data!) is enough to keep the lazy hacker from getting at your system. Anything beyond that and you're investing efforts to keep 'advanced' hackers/corps away. Please feel free to drop me line at work jean-luc.cooke@entrust.com. I'm a cryptographer who's implementing the AES here at Entrust Tech.

I'm posting this as AC because my friend wants to keep this under his hat, but I'll watch the comments and reply where appropriate.

Some interesting info on the relationship between Entrust and Thawte, and how this affects Entrust:

http://www.entrust.com/investor/12_21_ 99.htm

(Sorry for the double-post... I hit the wrong "reply" button the first time around...)

Disclaimer: I work for Entrust Technologies, and I deal with these sorts of problems every day.

For any decently secure system, you need at least two factor authentication. Pick two of something you have (smart card), something you are (biometric) and something you know (password).

Simple password authentication over a network like this is just not secure enough for things like medical records. Ideally, you would want to never send the password over the network, encrypted or not, since even with the password encrypted using SSL, you are still vulnerable to a "man-in-the-middle" attack.

The question states that "two factor authentication would probably delay the project a couple of years". This simply is not true anymore. Small plug here, but with something like Entrust/Secure Control, you can take your current system that is using only a username/password combo for access, and easily (in a few months) modify it to use two-factor authentication.

Not only does this give you better security for restricting access to the data, it can also provide a mechanism to encrypt that data in the back-end systems if you so choose. It also gives you non-repudiation, so you always know who it was that accessed that data.

Of course, you can achieve the same results using other products from other companies. Or you can do it using freely available systems if you have more time than money. The point is that adding two-factor authentication simply does not add two years to a project.

I'll assume that you have a working SSL/web-based system using username/password working right now. In order to convert this system to a basic two-factor authentication scheme, you need a couple of parts:

- Client-side software that will take the two-factors, and allow access to a user certificate. This cert is then sent to the server. (you can get products that will tie in directly to Netscape or IE and do this, so there is a very small 'learning curve' for this, but you do have to deploy client-side software and support it, so there is a cost associated with it.)

- Server side software that will take the certificate, verify if, check it against a CRL, and authenticate that user.

- Server side software that will take the users identity, as authenticated by the certificate, and allow them access to the back-end systems. This can be done with a database that ties the users Distinguished Name (DN) in the certificate to a username/password combo stored in a secure database, or by a more complex access system.

Of course, I can't really get into all of the details here, but for something as important as patient information, I would hate to see something as vulnerable as simple username/password authentication being used.

Perhaps the best way to force the issue of using better security is to involve the lawyers... if you implement and deploy a system which has known vulnerabilities, and someone's private information gets out, say hello to the lawsuits.

Oh yeah, opinions expressed are my own. I don't speak for my company. I am not a lawyer. Etc etc etc.

(Sorry for the double-post... I hit the wrong "reply" button the first time around...)

Disclaimer: I work for Entrust Technologies, and I deal with these sorts of problems every day.

For any decently secure system, you need at least two factor authentication. Pick two of something you have (smart card), something you are (biometric) and something you know (password).

Simple password authentication over a network like this is just not secure enough for things like medical records. Ideally, you would want to never send the password over the network, encrypted or not, since even with the password encrypted using SSL, you are still vulnerable to a "man-in-the-middle" attack.

The question states that "two factor authentication would probably delay the project a couple of years". This simply is not true anymore. Small plug here, but with something like Entrust/Secure Control, you can take your current system that is using only a username/password combo for access, and easily (in a few months) modify it to use two-factor authentication.

Not only does this give you better security for restricting access to the data, it can also provide a mechanism to encrypt that data in the back-end systems if you so choose. It also gives you non-repudiation, so you always know who it was that accessed that data.

Of course, you can achieve the same results using other products from other companies. Or you can do it using freely available systems if you have more time than money. The point is that adding two-factor authentication simply does not add two years to a project.

I'll assume that you have a working SSL/web-based system using username/password working right now. In order to convert this system to a basic two-factor authentication scheme, you need a couple of parts:

- Client-side software that will take the two-factors, and allow access to a user certificate. This cert is then sent to the server. (you can get products that will tie in directly to Netscape or IE and do this, so there is a very small 'learning curve' for this, but you do have to deploy client-side software and support it, so there is a cost associated with it.)

- Server side software that will take the certificate, verify if, check it against a CRL, and authenticate that user.

- Server side software that will take the users identity, as authenticated by the certificate, and allow them access to the back-end systems. This can be done with a database that ties the users Distinguished Name (DN) in the certificate to a username/password combo stored in a secure database, or by a more complex access system.

Of course, I can't really get into all of the details here, but for something as important as patient information, I would hate to see something as vulnerable as simple username/password authentication being used.

Perhaps the best way to force the issue of using better security is to involve the lawyers... if you implement and deploy a system which has known vulnerabilities, and someone's private information gets out, say hello to the lawsuits.

Oh yeah, opinions expressed are my own. I don't speak for my company. I am not a lawyer. Etc etc etc.

Disclaimer: I work for Entrust Technologies, and we deal with these sorts of problems every day.

For any decently secure system, you need at least two factor authentication. Pick two of something you have (smart card), something you are (biometric) and something you know (password).

Simple password authentication over a network like this is just not secure enough for things like medical records. Ideally, you would want to never send the password over the network, encrypted or not, since even with the password encrypted using SSL, you are still vulnerable to a "man-in-the-middle" attack.

You state that "two factor authentication would probably delay the project a couple of years". This simply is not true anymore. Small plug here, but with something like Entrust/Secure Control, you can take your current system that is using only a username/password combo for access, and easily (in a few months) modify it to use two-factor authentication.

Not only does this give you better security for restricting access to the data, it can also provide a mechanism to encrypt that data in the back-end systems if you so choose. It also gives you non-repudiation, so you always know who it was that accessed that data.

Of course, you can achieve the same results using other products from other companies. Or you can do it using freely available systems if you have more time than money. The point is that adding two-factor authentication simply does not add two years to a project.

I'll assume that you have a working SSL/web-based system using username/password working right now. In order to convert this system to a basic two-factor authentication scheme, you need a couple of parts:

- Client-side software that will take the two-factors, and allow access to a user certificate. This cert is then sent to the server. (you can get products that will tie in directly to Netscape or IE and do this, so there is a very tiny 'learning curve' for this, but you do have to deploy client-side software and support it, so there is a cost associated with it.)

- Server side software that will take the certificate, verify if, check it against a CRL, and authenticate that user.

- Server side software that will take the users identity, as authenticated by the certificate, and allow them access to the back-end systems. This can be done with a database that ties the users Distinguished Name (DN) in the certificate to a username/password combo stored in a secure database, or by a more complex access system.

Of course, I can't really get into all of the details here, but for something as important as patient information, I would hate to see something as vulnerable as simple username/password authentication being used.

Perhaps the best way to force the issue of using better security is to involve the lawyers... if you implement and deploy a system which has known vulnerabilities, and someone's private information gets out, say hello to the lawsuits.

Oh yeah, opinions expressed are my own. I don't speak for my company. I am not a lawyer. Etc etc etc.

Disclaimer: I work for Entrust Technologies, and we deal with these sorts of problems every day.

For any decently secure system, you need at least two factor authentication. Pick two of something you have (smart card), something you are (biometric) and something you know (password).

Simple password authentication over a network like this is just not secure enough for things like medical records. Ideally, you would want to never send the password over the network, encrypted or not, since even with the password encrypted using SSL, you are still vulnerable to a "man-in-the-middle" attack.

You state that "two factor authentication would probably delay the project a couple of years". This simply is not true anymore. Small plug here, but with something like Entrust/Secure Control, you can take your current system that is using only a username/password combo for access, and easily (in a few months) modify it to use two-factor authentication.

Not only does this give you better security for restricting access to the data, it can also provide a mechanism to encrypt that data in the back-end systems if you so choose. It also gives you non-repudiation, so you always know who it was that accessed that data.

Of course, you can achieve the same results using other products from other companies. Or you can do it using freely available systems if you have more time than money. The point is that adding two-factor authentication simply does not add two years to a project.

I'll assume that you have a working SSL/web-based system using username/password working right now. In order to convert this system to a basic two-factor authentication scheme, you need a couple of parts:

- Client-side software that will take the two-factors, and allow access to a user certificate. This cert is then sent to the server. (you can get products that will tie in directly to Netscape or IE and do this, so there is a very tiny 'learning curve' for this, but you do have to deploy client-side software and support it, so there is a cost associated with it.)

- Server side software that will take the certificate, verify if, check it against a CRL, and authenticate that user.

- Server side software that will take the users identity, as authenticated by the certificate, and allow them access to the back-end systems. This can be done with a database that ties the users Distinguished Name (DN) in the certificate to a username/password combo stored in a secure database, or by a more complex access system.

Of course, I can't really get into all of the details here, but for something as important as patient information, I would hate to see something as vulnerable as simple username/password authentication being used.

Perhaps the best way to force the issue of using better security is to involve the lawyers... if you implement and deploy a system which has known vulnerabilities, and someone's private information gets out, say hello to the lawsuits.

Oh yeah, opinions expressed are my own. I don't speak for my company. I am not a lawyer. Etc etc etc.

This is going to be a huge, huge, market. The music companies are the first ones to experience this. Hence, hardware companies are building end-to-end security. All of this is nicely outlined in the whitepaper that Entrust (investment from NatWest and everyone else in the money business) used to have online (they've investorified all their documentation into PDF). They say that you need a TCB (trusted computing base) to process the containers and my guess is that IBM is doing just that. It will be possible to hack this and Entrust even says so, but they don't worry, because legal steps are taken to make things "safe for business".

NSA? hehehe. Ever heard of the CSE? No? That's because in Canada we know what "Secret Gov't Agency" Really means! 290 Haron Road across from the Canada Post Place in Ottawa. Corner of Haron and Baseline Road. :)

3 office buildings. One of which has NO WINDOWS. The whole complex has a single enterance and exit. And guess who's accross the road? Entrust. A spawned company of Nortel. So what does Entrust do? Ever heard of CAST-256? Well it's an unbroken candiate for AES. Many crypto's (including myself) feel it's more secure than RC6.

But strangly, the CSE has approved all out deployment of the algorithim accross the federal gov't. Do you think they know something about CAST/encryption that the rest of the world doesn't?

Also developing encryption is good for Ontario business. Entrust Technologies is headquartered in Ottawa. I also recall the lead developer from the Ipsec presentation at the Ottawa Linux Symposium saying that he was from Ottawa. There's already a lot of software expertise in Ottawa and Toronto, so support like this makes it possible for Ontario to become a world leader in encryption.

As a new Ontario resident, I'm rather pleased, and pleasantly surprised to find a reason to like the Harris government.

Canada has similar export restrictions to the US. Any company wanting to export strong encryption needs to get a permit to do so. It's just that it is a whole lot easier to get that permit in Canada than it is in the USA.

Note how companies like Entrust have their headquarters in the USA, but the majority of their employees are in Canada. This makes it a lot easier to export their encryption software to other countries, yet still land US government contracts. Smart.

I'm not sure how this applies to Open Source software, though. Do the developers need to get the permit to export this still, even though they are not selling it? Tough call, but I'll bet that the government wouldn't pusue action against them if they did export it.

I don't know of any Open Source initiatives around this, but the standard you want to be looking at is PKIX-CMP. Check out the IETF draft.

There are also a lot of links to good white papers and other references at the Entrust Technologies resources page.