Subject: Minutes for the May 17th Trust elevation call
Minutes for the face-to-face meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee
17 May, 2012
1. Call to Order and Welcome.
2. Roll Call
Attending (please notify me if you attended the meeting but are not on the list below)
58 percent of the voting members were present at the meeting. We did have quorum.
2. Agenda review and approval
We used the following chat room for the call: http://webconf.soaphub.org/conf/room/trust-el chat room text is included at the end of the minutes.
Abbie asked if there were any additions to the agenda. There were none and we proceeded with the agenda.
Abbie asked Mary to lead the call.
3. Approve Minutes
Peter made a motion to approve the minutes of April 17.
Rebecca seconded the motion.
There were no objections. The motion passed.
4. IIW update
We held a session on Trust elevation at IIW to get feedback. Mary read in the notes from the IIW session (which are also available on the IIW wiki.)
This session included an overview of the OASIS Electronic Identity Credential Trust Elevation Methods Technical Committee (TC), its phase 1 deliverables and a request for input to structuring phase 2.
What is trust elevation?
Trust elevation - Increasing the strength of trust by adding factors from the same or different categories of trust elevation methods that don’t have the same vulnerabilities. There are five categories of trust elevation methods: who you are, what you know, what you have, what you typically do and the context. What you typically do consists of behavioral habits that are independent of physical biometric attributes. Context includes, but is not limited to, location, time, party, prior relationship, social relationship and source. Elevation can be within the classic four NIST and ISO/ITU-T levels of assurance or across levels of assurance.
This includes concepts of step up authentication, continuous authentication, risk based authentication and dynamic multi-attribute authentication.
This is different from the traditional 3 factor model. The ITU-T’s x1254 added the behavioral factor and we elevate context to a fifth factor.
We reviewed some representative method examples captured in our survey. See below for link to TC’s website.
Why is it becoming more important
More and more, when dealing with consumers and citizens, there is a need for dynamic authentication. A customer should only be asked to do multi-factor auth when they want to do high value transaction, not as a prerequisite to visiting a website. Few consumers have high LOA- credentials.
Technical Committee’s three phase approach
• Phase 1 - a survey of methods of trust elevation and a taxonomy of five method factors (done)
• Phase 2 - an analysis of the methods, which methods counter which threats and are complimentary, etc. (starting to structure the analysis)
• Phase 3 - a proposed protocol
We had a good session. People were comfortable with our five factor taxonomy.
We discussed different ways to talk about the inflexion point in the adoption of more dynamic authentication (rather than authorize once and you are done, authentication.)
The chief feedback was that the analysis should include the dimensions of a privacy and making processes acceptable to users (usability and adoption can be as important as risk management in some sectors.
Rebecca commented that it was disturbing that there was so much focus in the IIW session on privacy and ease of use. These issues shouldn’t trump security.
Mary commented that Identity Commons and its IIW working group have a particular emphasis on privacy, so the comments should be taken in context.
It was also commented that ease of use is key to adoption.
5. Presentation by Steve Kirsch on Trust elevation (http://www.oneid.com/for-individuals/features#simple)
Mary introduced Steve Kirsch, the Founder and CEO of OneID, and Jim Fenton, from OneID.
Steve said that the presentation link is listed in the chat room.
Slide 2 – With OneID there is no compromise between privacy, security and ease of use. It is a have you cake and eat it too approach that is quite unique. OneID addresses auth. Securing end points is unrealistic.
Slide 3 – Identity management is badly broken. That is why NSTIC was created. When EMV cards roll out in the US, credit cards will be secured with pin and chip. When these were rolled out in Europe, fraud migrated to be more online. So things will get worse, more breaches, Password are not sustainable.
Slide 4 – It is the use of shared secrets (and centralized storage of same) that creates centralized risk. That centralized risk is present in virtually every popular system.
Slide 5 – Thirty years after invention of public key crypto, the number of consumer websites that allow login without the use of shared secrets is zero.
Slide 6 – User auth today is shared secrets. You may have robo form filling to help, but that just moves vulnerability to the SSO system. Malware on the PC can steal all your shared secrets.
Slide 7 – About a year ago, Steve got frustrated with UN/PW and thought there needs to be a better way. He created an out of the box solution as he was not experienced with auth. He did research, and ran it by experts and it involved into a very elegant architecture. You authenticate to your device. The password is only shared with the device so there is no centralized security risk. Your phone asks do you really want to do this. If yes, than logged in. If want higher levels of security, it can also prompt you for a pin code on the device. So there are two device factors. This is simple. It is way more secure and fun than secureID. It has ease of use. It uses one convenient device to prove that you are you.
Slide 8 – Click OneID to sign-in for site. Can also set security levels on each site. You can require out of band factor on Facebook. When on site can use OneID form fill. Also OneID check out, which operates under the covers with no display if someone is looking over your shoulders.
Slide 9 – Is the heart of how the system operates. It breaks identity over three devices, and by doing that, we get a lot of security. So if you are on public terminal, which is insecure, then the repository knows where your approval devices are. If confirm on approval device, then that device will generate a digital signature and send it to the repository in step number 4. Step 2 got what needed to do the crypto. Step 6, takes signatures and sends to RP. RP verifies sign-in. (Hit space bar to see builds for this slide.)
Steve paused to ask for questions.
There was a question about the signature.
Steve responded it is an ECCP256 digital signature. There are ECC private keys associated with the three public keys the website has for me. So we use asymmetric cryptography.
Shahrokh asked is the repository on one of the devices?
Steve replied it is on the web as part of the service. You can choose who you want your identity to be stored with. So ABC could say they want to store and one of provisions of NSTIC is to have choice. So OneID is providing software, in much the way that Visa sets standards and you can get a card from any issuing bank.
There was a comment that another example is someone may want to have their stuff stored in a specific jurisdiction.
Steve said that the public keys are unique for any website, so there is no trackability across websites. It is privacy in an elegant matter. The website only talks to the user. So the store doesn’t know about the RP and vice versa. It is all private, secure and provides ease of use. There is no download. It works on any modern web browser with HTML5 and storage facility.
Shahrokh of Intel said we love this as it means people need to have two devices. The biggest problem is how do you reach that level of trust when you only have one device with you? What if you are in the car and have a phone, but not a laptop, and there is not a second device in your car to authenticate you. How do you see this resolved?
Steve said we give people choices to trade off between security and liability. You can use the mobile phone and browser to log in. You can dual purpose the phone as an approval device. That does slightly increase risk to mobile phone maleware (risk depends on phone OS). The other option, is you have your cell and you have an iPod, you use it only for out of bound approval, that is you only use for that, so it can’t be compromised with malware. Most people won’t be challenged for out of band for consumer use. Amazon only does it if it is an unusually high dollar amount or address. You have choice.
There was a question, when you are communicating with the phone are you using the data channel?
Steve said yes, we are using the data connection.
Slide 10 – How do you generate these things and get them from device to device; and take a centralized risk and change it to a decentralized risk? First you generate digital secrets on the device. So you when sign up, we generate crypto secrets on your device. To move crypto secrets device to device in a user friendly way is with a paring code. If sign-in with existing identity, it will ask for password/pin code that is only kept on the device, it gives you a pairing code that you enter into your old device. They are both contacting a signing server (patent pending.) Even if pairing code is compromised, attacker can’t learn your secrets. Can do an end-to-end transfer of crypto secrets between devices.
Steve paused for questions, and noted that Jim was co-inventor of that technology.
Slide 11– The problem today with credit cards is you are always sharing the secret every time you check out. At OneID we want to eliminate the use of shared secrets. That will probably happen in stages. When check out from JC Penny, they send a digital invoice, user signs with device key and repository signs as well. If big $$, may involve out of band device. That is a requirement that I set up with my bank. So I have 2 or 3 digital signatures associated with that transaction. Also have name of credit card like Steve’s Visa. User gives invoice back to JCP with a unique number so it can’t be replayed. Penny sends it to the bank. The bank compares the digital signature to what he has on file, tells First data, the acquiring bank. So the point of this is you have an end-to-end digitally secured transaction. And the bank knows exactly what they are approving as well. This eliminates PCI risk for merchants. It eliminates the expense of PCI compliance and liability. This could be used for any authorization.
There was a question about the end to end time for users.
There was a question, are these soft certs?
Jim replied yes, soft.
It was noted that we were running out of time and, and Mary asked Steve to jump to slide 23 which has an matrix of threats and counter measures.
Skip to slide 23 – For online and offline and over the phone, you need to compromise 6 secrets to win the prize.
Columns are crypto key on computer and on approval device; and devise id number on access devices and also on control device. Also password and pin on both options.
Phishing attacks can get can get 2 out of 6.
Malware can get 3.
Physical attacks can get two depending on the device.
So it would take a physical attack on both devices, plus phishing to get all the keys.
Steve would be happy to share his email address, if people have question after this.
Mary thanked Steve for his informative presentation.
6. Editors update on deliverable 1, ballot results
There were 19 votes in favor and no votes against.
7. Editor discussion on Second Deliverable (Analysis phase)
There was no time for this agenda item.
8. Attendance Update
We achieved quorum.
Shaheen made a motion to adjourn.
Rebecca seconded the motion.
The meeting was adjourned.
Abbie: Trust Elevation TC CHAT ROOM
1. roll call
2. agenda approval
3. approve minutes
4. editors update on deliveable 1, ballot results
5. IIW update
6. Editor discussion on Second Deliverable (Analysis phase)
7. Presentation by Steve Kirsch on Trust elevation (http://www.oneid.com/for-individuals/features#simple)
abbie: Steve Presentation is at http://www.oasis-open.org/apps/org/workgroup/trust-el/documents.php?folder_id=2575
anonymous morphed into Jim Fenton
anonymous morphed into steve kirsch
anonymous morphed into Shahrokh Shahidzadeh (Intel)
anonymous morphed into Suzanne Gonzales-Webb
Shahrokh Shahidzadeh (Intel): Question: Does the repository sit on either of the two devices?
steve kirsch: no, the repository is ALWAYS a third party provider, never the user