Pretexting and Privacy

I've never seen Craig Burton write about privacy before.  Clearly he's had enough of the recent goings-on: 

  1. I was listening to Talk of the Nation on National Public Radio this afternoon. There was a good discussion going on sparked by the fiasco that happened at HP the last few weeks. Since I cover lexicon, identity, and security, I thought it would be a good idea to cover some of the conversation.
  2. What has emerged new to the general conversation is the term “pretexting”. This is the practice that investigators–both private and internal–use to pretend that they are someone else to obtain personal information from service companies. This includes, the phone company, cell phone companies, banks, utilities, county ownership records, and other private and public agencies.
  3. This is not a new term, but one that is getting public recognition as a result of the HP fiasco.
  4. According to the conversation that I heard, there is a synonymous term in the hacker community for pretexting called “social engineering.” There are some states that have made pretexting and social engineering illegal. California, Tennessee and Florida are exceptions maybe. This is a gray area and is only coming to light after these events.
  5. The previous hacker turned consultant in the conversation is the author of the book The Art of Deception.
  6. Here is my take on this. The government and agencies are not going to be able to cope with this problem. This means that it is your responsibility to protect yourself. There are a few major areas that you can focus on that will help you.
  7. Use InfoCards for login when you can. I admit this is new stuff, but it is fundamental in protecting your information from phishing and hijacking. InfoCard technology will change the future of hackers and thieves. You can support this by understanding it and using it.
  8. Stop using common methods of identification. Your social security number, you mother's maiden name and your birth place are redily accessible to social engineering agents.
  9. Use encryption for your data and emails. There are several technologies that will help you with this. You can do it at work and for your personal emails where needed. Without encryption, you have to assume that your emails are totally accessible to anyone who wants them. The current email technology is hackable and in clear text that is readable by anyone.
  10. You have to assume that at work, there are people keeping track of what you do with your computer. This is an issue, but you can also understand that your employer probably doesn't have the resources to look that closely at what you do.
  11. However, they also had a guy on the program that was being offered a job–a high profile and high paying job–that was revoked after the person had some email conversations about the terms of employment with his attorney. The company actually monitored his email conversations and gave him the choice of resigning or being fired as a result of the interchange. Scary.

Ms. Dunn at HP has struck a deal with the HP board to resign as a result of the press and fiasco. Did she know what the legal dept. was doing? Probably not. My opinion is that she should have found out on an issue of this importance at that she should probably step down now and not later.

I appreciate his comment about the role of Cardspace. 

And while we're talking about Craig, Has everyone seen his recent Poser sculpture entitled, “If I just give this Web 2.0 bubble a flick, nobody will get hurt, right?“:

First Information Cards for Safari

click to download movie One of the best moments of the DIDW show, for me, came when Ian Brown, an old friend of Chuck Mortimore, showed us his Identity Selector for Safari.

If you don't know Chuck, he single-handedly wrote a Java-based InfoCard Identity Selector that runs inside Firefox on almost any platform.  He gave me a copy, helped me install it on my computer, and it all just works.

Later I'll do a screen capture of Chuck's work since i can run it on my own machine. 

But I don't currently have a Mac – so Ian succumbed to my goading and put together a little video so you could see what he's working on.

That's such good news.  As he says, “For the faint of heart, or for those running those other operating systems, here's a short screencast of the Safari identity selector in action, authN'ing against Kim Cameron's RP…”

Meanwhile, here's what he says about the actual plugin:

This is currently still at the proof of concept stage, and is lacking most of the features found in the official CardSpace selector from Microsoft. At present, only a single self-asserted card can be selected. The “selector” will currently pull the logged in account's personal information from the AddressBook application, and allow you to use that AddressBook entry as a self-asserted InfoCard with various RPs. It should work with existing installs of Safari, and with most relying parties.

The plug-in itself is a wrapper around Chuck Mortimore‘s Java implementation of an InfoCard token generator. For those of you out there using Firefox, check out Chuck's cross-platform Firefox InfoCard selector.

So download the Safari Plug-In below and give it a spin. Send me any feedback at igb at hccp.org

I'll post new releases here as features are added and bugs are fixed.

Downloads

Currently there are two versions, one for the new Intel-based Apple's, and one for the PowerPC-based machiines. At some point I'll figure out how to get XCode to generate a Universal Binary. (I suppose the PowerPC build might work on the Intel Macs, that's what Rosetta is all about right? But it hasn't been tested on the Intel arch, so YMMV.)

Intel version
http://www.hccp.org/InfocardPlugin.bundle.zip
PowerPC version
http://www.hccp.org/InfocardPluginPPC.bundle.zip

Installation

Installation is pretty simple. After downloading the ZIP file, extract the archive. You should now have a file called InfocardPlugin.bundle. Just copy that to the Library/Internet Plug-Ins directory under your home directory. restart Safari, and off you go.

Despite Ian's self-depricating style I think what he and Chuck are doing is amazing.  And it shows what can and will be done.  Meanwhile, Apple People, download Ian's plugin and leave comments on my blog.

Namespace change in Cardspace release candidate

Via Steve Linehan, a pointer to Vittorio Bertocci's blog, Vibro.NET:

In RC1 (.NET framework 3.0, IE7.0 and/or Vista: for once, we have all nicely aligned) we discontinued the namespace http://schemas.microsoft.com/ws/2005/05/identity, substituted by http://schemas.xmlsoap.org/ws/2005/05/identity. That holds both for the claims in the self issued cards (s-i-c) and for the qname of the issuer associated to s-i-c. If you browse a pre-RC RP site from a RC1 machine, you may experience weird effects. For example, like the Identity Selector claiming that the website is asking for a managed card from the issuer http://schemas.microsoft.com/ws/2005/05/identity/issuer/self no longer recognized as the s-i-c special issuer. Note that often is not a good idea to explicitly ask for a specific issuer 🙂

 If you want to see a sample of this, check out the updated version of the sandbox.

Why this change? As you may know, relying parties specify the claims they want the identity provider to supply (for example, “lastname” or “givenname”) using URIs.

Everyone will agree that the benefit of this is that the system is very flexible – anyone can make up their own URIs, get relying parties to ask for them, and then supply them through their own identity provider. 

But a lot of synergy accrues if we can agree on sets of basic URIs – much like we did with LDAP attribute names and definitions.  

Given that a number of players are implementing systems that interoperate with our self-asserted identity provider, it made sense to change the namespace of the claims from microsoft.com to xmlsoap.org.  In fact this is an early outcome of our collaboration with the Open Source Identity Selector (OSIS) members.  Now that there are a bunch of people who want to support the same set of claims, it makes total sense to move them into a “neutral” namespace.

While this is therefore a “good and proper” refinement, it can pose a problem for people trying out the new software:  if you are using an early version of Cardspace with self-issued cards that respond to the “microsoft.com” namespace, it won't match new-fangled claims requested by a web site using the “xmlsoap.org” namespace.  And vica versa.  Further, the “card illumination” logic from one version won't recognize the claims from the other namespace.  Cardspace will think the relying party is looking for specialized claims supplied by a “managed card” provider (e.g. a third party).  Thus the confusing message.

After getting some complaints, I fixed this problem at identityblog: now I detect the version of cardspace a client is running and then dynamically request claims in either an old dialect or the new one.  I would say people would do well to build this capability into their implementation from day one.  My sample code is here.

Radia Perlman on PBE

The ever-interesting James McGovern posted about Encryption Based Encryption a while ago, wondering if Microsoft and Sun might add it to their product suites.

I was so busy travelling that I got swept away by other issues, but Sun's Pat Patterson persisted and recently posted a cogent note by Radia Perlman, one of his colleagues, which I thought hit a lot of the issues:

Identity based encryption.
Sigh.

This is something that some people in the research community have gotten all excited about, and I really think there's nothing there. It might be cute math, and even a cute concept. The hype is that it makes “all the problems of PKI go away”.

The basic idea is that you can use your name as your public key. The private key is derived from the public key based on a domain secret, known to a special node called the PKG (private key generator), which is like a KDC, or an NT domain controller.

Some of the problems I see with it:

a) public key stuff is so nice because nobody needs to know your secret, and the trusted party (the CA) need not be online. The PKG obviously needs to be online, and knows everyone's secrets

b) If Alice is in a different trust domain than Bob, she has to somehow securely find out Bob's PKG's public parameters (which enable her to turn Bob's name into a public key IN THAT DOMAIN).

c) Bob has to somehow authenticate to the PKG to get his own private key

d) There is no good answer to revocation, in case someone steals Bob's private key

e) There is no good answer to revocation, in case someone steals the PKG's domain secret.

I've seen hype slides about identity based encryption saying “which identity is easier to remember?

In PKI: 237490798271278094178034612638947182748901728394078971890468193707
In IBE: radia.perlman@sun.com

This is such ill-conceived hype. In PKI no human needs to see an RSA key. The RSA key is not your identity. Your identity is still something like radia.perlman@sun.com

So, it looks like IBE gives with one hand (sender can create a public key without the recipient's involvement) but takes much more away with the other (key secrecy, PKG has to be online, revocation issues). I guess there is no such thing as a free lunch…

Let me put the same points just a bit differently. 

IBE is very interesting if you think everyone in the world can trust a single authority to hold everyone's secrets. 

OK, now let's move on.

When you do have multiple authorities, you need a way to discover those, so you need a secure email-to-authority mapping and lookup.  Yikes.  The only way to do that which is simpler than public key itself, is to use mail domains as the authority boundary combined with some kind of secure DNS.

But in that case, your mail server can decrypt anything you receive, so it's no better than a conventional edge to edge encryption scheme (e.g. where mail from me to Pat gets encrypted leaving the Microsoft mail system and then decrypted when entering the Sun mail system). 

Edge encryption is pretty well what everyone's building anyway, isn't it?  So what's the role for PBE?

My vision is that one day, Information Cards will be used to convey the information needed to do real end-to-end encryption using asymmetric keys – without the current difficulties of key distribution.  This said, signing interests me a lot more than end-to-end encryption in the short term.

More about this some other day.

Practice equals theory – demos OK

In terms of certificate behavior, at least, all the metasystem components worked together as designed, across platforms and operators, during the recent change of site key and SSL certificate at identityblog.

I have to give textdrive.com, the operators of my site, credit for going through this on extremely short notice and without charge.  You could look at it as a proof of their ability to handle an emergency revocation, and another example of what a good company they are.

When using Information Cards in the most basic configuration, as I do on my site, the SSL certificate is also used for encryption of the WS-Trust token sent from the identity provider, so everything has to line up at the transport and message level.  The good news is that all this worked as predicted.

It's now fine to use the site for demos – with only the usual caveats… 

One more Paul on the federation and user centrism demo

Incredibly, I just came across a comment by another Paul.  I guess I spoke to soon about my success communicating with Pauls, since Paul Madsen seems to be a doubting Thomas – which in this case adds some variety, so I'm pleased to see it: 

Kim Cameron has a screen cap movie of a demo created by Ping ID.

Kim asserts that the demo illustrates (paraphrasing) “user-centric technologies like Information Cards are not in any way counterposed to federation technologies”.

I completely agree with the sentiment, but question whether the scenario portrayed by the demo actually demonstrates it.

In the demo, a user authenticates to a portal using CardSpace. Once authenticated, they are presented with a list of applications available to them for which SSO is possible (this presumably dependent n which I-Card they selected). For Kim, the user-centric piece (CardSpace) somehow ends at the portal, and from then on federation (SAML etc) takes over.

So, user-centric and federated technologies are shown as working together – but not at the same time. The user-centric piece hands off to the the federation piece. Federation is presented as a lower-level piece of infrastructure (which it can be) that doesn't seem to touch the user.

Hmmm.  What I'm really saying is that in the demo being shown, the user has a relationship with the portal, which offers a nice array of services.  So in terms of technology, the identity relationship is user-to-portal, not user-to-individual-service.  One could also say the “services” can be “outsourced” by the portal – and are dealing with users as proxies for the portal.  Once the user has entered the portal, there is a “magic carpet” that takes her from service to service. 

But note:  The portal could also take the user to a service with which she would have a completely independent identity relationship.  In this case, the user would again see the Cardspace interface and select her identity through it.

Paul (three) continues:

This interpretation is reinforced by Kim:

To my way of thinking, you have two more or less orthogonal technology efforts – that oriented around federation issues, and that oriented around the user’s experience.

This ignores the possibility for SAML-based technologies to provide the very same user-experience (i.e. real-time identity sharing control, IDP selection etc) that I-Cards enables. Is SAML's Enhanced Client or Proxy (ECP), as it enables similar control mechanisms, then user-centric?

Probably not, as Kim also hilites the common UI of Cardspace and its relevance

Should my experience therefore be totally discontinuous as I move from one portal to another, being organized by the portal rather than by my own system

Exactly.  Maybe I was more successful at communicating with Paul Masden than I initially thought – I think he sees my point. 

The portal just cannot know all my identity relationships (unless I were to find myself in some hiddeous “total environment” where everyone knows everything). 

So the portal, simply by virtue of the role it plays in the system, cannot organize my perception and use of identities across the board.  This is one of the key points I'm trying to make, and explains why you need user centric technologies and they are orthogonal to federation technologies even though in both cases you have claims being asserted and relied upon.

Finally, Paul asks:

If the phone manufacturers (or those of set top boxes) were to come together and agree on user-interface standards – would that be user-centric?

If they allow users and relying parties to represent and select between their multiple identities then yes, sure, exactly.  But it's not just a question of user interface (UI), it's a question of capabilities that are represented through UI.  I don't know why people reduce this to UI.

The fact that phones could deliver these new capabilities is why it makes perfect sense to put Information Cards on phones, music players, and other devices.  I first proposed putting them on computers because I happen to work in that industry.  But I know a lot of people who are interested in getting the same identity relationships to appear across all kinds of devices.

Demo gets good reviews

Paul Toal over at Identity, Security and Me posted this to encourage you to check out the demo I put up recently.  (Just in case any of you are busy, it's only 3 minutes long!)

Picture of Britian's Paul ToalKim Cameron has posted a really good video here explaining how user-centric identity and federation can work together. His blog and associated demonstration is shown using Microsoft CardSpace and Ping Federate from Ping Identity.

I have worked with Ping Identity for some time and was happy with the product and how it, and federation works generally. However, like Paul Squires here, I was struggling to see how it fitted within a user-centric architecture. Whilst I saw the two as complimentary, I didn’t see the link.

This video has clarified this for me and shown that there is a clear interaction between the two.

As usual Kim, thanks for a great demo! If you haven’t seem the demo yet, you HAVE to view it.

Then, following Paul Toal's link to Paul Squires at Here, Now, I came across his additional comment:

This [demo…] is well worth seeing for anyone with an interest in where digital identity is going. The demo itself shows cardspace (if there’s anyone who hasn’t seen it yet!) along with interoperability between a number of applications. The guys at Ping have done a great job with this and I’d hope this brings together these various strands of identity management (it’s certainly helped me, not least from an architectural point of view). Things are starting to look very exciting!

Update: Never one to miss out on a bit of vanity, the second open tab in the browser during the demo looks very familiar!

Gee, I'm on a roll.  Just like my horoscope said, I seem to be communicating well with people named Paul.

As for Paul two's “update”, looking closely I also can see that I had been reading one of his posts the day I captured the demo.  Just think.  Some people are worried there will be no fingerprints in the digital world.  It ain't true.

Federation and user-centricity

Conor Cahill picked up on a discussion I recently relayed to identityblog readers – part of an ongoing dialog between Brett McDowell and Dick Hardt.  Conor says:

I think the issue causing the disagreements here is the interpretation of the term “federation” when discussed in an identity context.

Certainly federation can mean groups of businesses working together and this is the traditional meaning of the term in the business community. This meaning would fit with Kim's statement above.

However, in an identity context (as in “identity federation” — the stuff the Liberty Alliance has been working on since its founding) the term federation was used to describe the sharing of identity information from party A to party B. Party A is usually some party representing the user (acting on the user's behalf) such as an Identity Provider or an Attribute Provider. There is nothing that says whether Party A is an entity operated by the user or by some 3rd party.

In fact, in the Cardspace solution, the process of sending data through an Infocard instance to a relying party would be considered taking place under identity federation, whether the infocard instance was rooted in a local data source or a remote data source.

Ultimately, I would say that federation can be used in both user centric and non-user centric solutions. Federation is a technology/protocol and user centric is an implementation philosophy. When designing a user centric solution, you almost always have to include some form of identity federation, but give the user great control over its use. The converse is not required to be true (although I wouldn't object to it if it was true in any environments in which I played).

I like a lot of Conor's thinking.  I agree that use of a managed card in Cardspace should be considered a form of “federation” between the relying party and the identity provider – federation approved by the user.

But I don't quite buy that “federation is a technology/protocol” wherease “user-centric is an implementation philosophy”.  I doesn't compute given a great deal of work I've been doing lately.

It's clear to me that good “user-centric” experience isn't just an automatic or natural by-product of some other “technology/protocol”.  In fact, it requires just as much study, just as much thought, just as much coding, and just as much experimentation as protocols do – probably more. 

What I'm try to say here is that it requires technology.   In the past we've had a lot of technology that failed miserably at organizing, integrating and rationalizing the user's experience.  I've been working on software that I think does a lot better job at this.  Why wouldn't Conor call that a technology?

To my way of thinking, you have two more or less orthogonal technology efforts – that oriented around federation issues, and that oriented around the user's experience.

As a user, when I go from portal to portal to portal, it's likely they will have relationships with different identity providers.  Should my experience therefore be totally discontinuous as I move from one portal to another, being organized by the portal rather than by my own system?

In Cardspace (and with Information Cards running on other devices and platforms) we postulate that the user can benefit from computerization of his or her own identity experience – just as enterprises benefit from computerization of theirs.

Through Information Cards users can benefit, to the extent the technology is adopted, from the same well-understood experience as they move between unrelated portals which do not share identity relationships.   

I see Cardspace as providing a palette of identity relationships (Information Cards) that work for me as a user and make sense from my point of view as an individual with a complicated life. 

I think Dick Hardt, and others like Paul Trevithick at Higgins, share a number of the same notions as I do, though each of us is concentrating on different aspects of the problem.

So that's why I'm saying that there are two legitimate technology areas, orthogonal in the sense that you can have either one without the other, but synergistic in that together you get a number of critical new scenarios.

To make this more concrete, my next post will be  a demo of Andre Durand and Ashish Jain's work in showing how this can look in practice.

Adventures in Cardspace

Industry guru Craig Burton's Cardspace is working now (thank goodness).

The bad news is that he's had a pretty miserable time getting it going.  Mainly, it seems in retrospect, because his computer was set up with a FAT32 file system.  If you have this configuration, no error message is displayed to you as a user – you have to read through a cryptic note in the system-wide error log.  This has to be fixed.

The good news is that once he got Cardspace working, Craig really liked it.  That's really important to me:

I have been trying to get CardSpace to work on my machine for several weeks. (Seems much longer.)

I have downloaded tons of upgrades, deleted apps and services, and so on.

Pamela Dingle and Kim Cameron have been very helpful in trying to help me make things work.

Pamela studied the error log –created by the CardSpace control panel–I posted and suggested that the problem was that my c: drive was using the FAT32 file system. She explained that her resources tell her that CardSpace only supports NTFS.

Turns out this is true. Kim subsequently fessed up that FAT32 isn't secure enough so they decided to set the bar at NTFS. They just didn't bother to tell anybody. (Good thinking.)

I decided–against my better judgement–to convert my FAT32 file system to NTFS. I haven't done that until now because I haven't been successful in creating an NTFS compatible boot CD. If something happens to my system, I'm in trouble. I am working on resolving this. (There is a DOS-based utility that will access NTFS for recovering critical data. I don't like that prospect.)

Anyway, to convert from FAT32 to NTFS you do the following. Open a command line window:

start>run>cmd

Run the convert utility:

convert c: /fs:ntfs

Reboot, and the convert utility–assuming you have enough empty storage–will convert FAT32 to NTFS with no loss of data.

I tried it. It worked. Whew! Getting this far has been no simple task.

I was then able to create an Infocard with the CardSpace control panel and login  to the Idendity web log and to the NetFX Sandbox.

I also tried the Ping site . It was slow–not sure why–but it worked. A page came up with four other sites that support Ping Federation that I can sign into with my Infocard. The sites aren't all the useful to me, Java, Verisign, Computer Associates, and another one I can't remember. That was cool.

The Ping site–unlike the other two sites–gave me three options for signin:
Traditional (yuch) name and password, self issued Infocard or Managed Infocard. Not sure why ping distingshes between self-issued and managed Infocards as the Infocard selector lets you do that, but I will find out.

Caveats.

If you convert to NTFS, you cannot go back to FAT32 without repartioning and formatting your disk.

I love being able to register and login to a website with an Infocard…SWEET!

I hate how complicated it is and that it only works with BETA code. Infocard simplicity comes at a complicated uphill price. At least it isn't Msft-silo-centric. Apple, Mozilla, RedHat and others have commited to support Infocards.

Things will have to get significantly easier–and supported by other browsers and OSs–before we see any kind of adoption.

Despite all of that. Not having to use name-password mechanisms for secure interaction is very significant to the industry and people. This has been a long time coming and I can't emphasize its importance enough.Thanks to all that have made it happen. 

Many thanks to Pamela, who has become a Cardspace savante, for figuring this out – I've been in Australia and couldn't keep up with the troubleshooting.

William Tay on converting public key pair formats

William Tay has a very interesting technical blog and has solved the riddle of how to take a public key pair that he produced in a Microsoft environoment, and export it to PEM so it can by used by PHP.  I didn't have this particular problem, because I created my site's key using OpenSSL in the first place.  However, I've spent many hours with the OpenSSL utility trying – so far unsuccessfully – to go the other way (PEM to pfx).  It shouldn't matter which platform you create your key on – if you have a mix of platforms you want to be able to take the key in both directions.  Anyway, for those who have William's problem, here's how he dealt with it:

I believe some hardcore Windows CardSpace fanatics out there may have tried out Kim Cameron's IdentityBlog Cardspace demo on php. The tutorials can code samples can be found via his blog here. As of this time, I dont think he has updated it to work with the WinFX July CTP drop.

If you had played with those php samples, you will realize that nothing much has changed for the WinFX July CTP drop, we are still using the same version of WS-Trust and WS-Security Specifications specifications. While WS-Security has been pretty much baked, as the advanced WS-* specifications reach a better level of maturity and acceptance, it won't change as frequently anymore.

The only change to take note is the OBJECT element in the html page. The way claims are presented on a html page is now space-delimited and not comma-delimited as it was before.

I have been showing the php demos in my presentations around the Asia-Pacific circuits for some time now. One of the questions I frequently get asked is how do we get the RSA private key of the https site (Relying party) we are using to authenticate our users. While Kim has shown some briefs snippets of his php code here (It is fairly obvious why the entire Private Key cannot be disclosed here),

// Cardspace_demoprocessing.php
// Put your own PEM private key here and
// use the right password (for the demo
// we don't use MySql to store this stufffunction get_settings($key)
{
    if ($key == “infocard_key”) {

$retVal = “—–BEGIN RSA PRIVATE KEY—–
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,9266952B733BFBE0

Z4WmpirV4dXvYjNmfSN99Iu4iYzUWa4/CPZG0NParYSVHMOhb4lsS6iISjgniGG9
zhA862KDwsYUjgoyAIXfJAd5Z3hXiyJYdkygF/DUgeQFcwQjsWmkguq27EDHW6nS
.
.
.
3GkQxPLzTMFZYm7haU3WH+QYnNxz2bG0esUmB/YECXDCqFTbrUm/DUPd4YiI2HiL
+j40vRpPzY6ngd1QNOfd5jkin7sjW1YlsEsRPV8OzEJvNmBZF274Cw==

—–END RSA PRIVATE KEY—–“;

    }
    else if ($key == “infocard_opener”){
        $retVal = “xY8O< |aBB";     }     else {         $retVal = NULL;     }     return($retVal); } he did not show how he got that RSA Key. There are, of course, a few ways to get that key. But since we are on the subject of Open-source and php being the flavour of the day, I thought why not show the readers how to get it using another popular utility out there called “OpenSSL“. I am using version 0.9.8b the OpenSSL binaries/executables.

Once that is all downloaded, installed and setup – I used this command to retreive the RSA Private Key into a PEM file:

Openssl pkcs12 -in Softwaremaker.NET.Pte.Ltd_300607_SSLCert.pfx -out cert.pem -nodes

You will, of course, replace the “Softwaremaker.NET.Pte.Ltd_300607_SSLCert.pfx” with your own site's SSL digital certificate. The -nodes flag just tells the output not to have a passphase lock on the resulting PEM file. Of course, you can if you want to if you are afraid of others being able to view your site's Private Key from the php code file. The output cert.pem will contain the output:

Bag Attributes
    1.3.6.1.4.1.311.17.2:
    localKeyID: 01 00 00 00
    Microsoft CSP Name: Microsoft RSA SChannel Cryptographic Provider
    friendlyName: 1a9c651d1153bf0e58ac3ff34c9fce1f_615cbd1c-54d4-4ea0-b0d4-5c14115c3abb
Key Attributes
    X509v3 Key Usage: 10
—–BEGIN RSA PRIVATE KEY—–
MIICXgIBAAKBgQDElLoxJcOzWT0jHT6uvdDHpDBnZLa4AE/gznjcKuSIT880MAmL
ADVIoDP/0MPDucexjWCtJ33msRCmi2TOQ86dPhyc/kfrmpTnjG+Kwi7tR5x07rAM

XLj+knD7VxrZvE/CBJP5PgjuvqfcbiSGf4R8dVB/nVm6tw==
—–END RSA PRIVATE KEY—–

Bag Attributes
    localKeyID: 01 00 00 00
    friendlyName: Default Web Site
subject=/C=SG/ST=Singapore/L=Singapore/O=Softwaremaker.NET Pte Ltd/OU=Software Development and Architecture Research Unit/CN=swmvm2k3
issuer=/CN=Softwaremaker.NET Pte Ltd
—–BEGIN CERTIFICATE—–
MIIE1DCCA7ygAwIBAgIKYVFrDgABAAAACDANBgkqhkiG9w0BAQUFADAkMSIwIAYD
VQQDExlTb2Z0d2FyZW1ha2VyLk5FVCBQdGUgTHRkMB4XDTA2MDYzMDAyMjkyNFoX

Gl+c093/wY1RT9FhAyK0vpP/H9rFzyrCZbuyL69tWkTI1DGTuZHW5g==
—–END CERTIFICATE—–
Once you got the above output, you just have to replace the “—–BEGIN RSA PRIVATE KEY—–…” until the “—–END RSA PRIVATE KEY—–“ with your own in the php code file (Cardspace_demoprocessing.php).

Hope this helps someone out there.

Yeah.  It's true that I was unclear, when writing my demo PHP code, how to best store and retrieve secret keys in a LAMP environment.  In Windows, I would use the system-provided routines for protecting and accessing secret keys, but I don't know the equivalents one would use in LAMP.

I ended up just storing my keys in mySql (the code William shows above is a simplification to make the issues as easy to understand as possible) – but I'd appreciate hearing from someone who knows the proper way to do this.