Over the last couple of days I have had numerous people point me to a post on Adobe's blog about PIV card usage. For those of you not familiar, the PIV card is the US governments implementation of an end-to-end specification for identity issuance to its employees and approved contractors. The standards that support PIV come out of the work that followed on from Homeland Security Presidential Directive 12 (HSPD-12) and they address the technical specifications for the card including the specifications of the digital credentials on the card as well as the process for issuance and most of the things that build around that. The PIV specification was then leveraged to implement a credential for non-Federal entities that may wish to interoperate with the US Federal government and this is called PIV-I for PIV Interoperable. PIV and PIV-I credentials have been rolling out over the last few years and the PIV-I market is growing quickly with interest from companies that provide products and services to the government, state and local governments and now growing into the healthcare arena.
The post by Adobe was very good in that it talked about usage - and how these cards can be used to sign documents electronically and then provide a way to validate them - but there were a few things in there that hit the wrong chord. Let me explain .....
First off the post talks about validating credentials per the US Federal Common Policy. Well the US Federal Common Policy does not tell you how to validate a credential. It specifies the policy under which you would operate a PKI such that it could be trusted by the Federal agencies. NIST did create a set of tests, PKITS, that would let you know if your product could validate a certificate, and thereby signature, properly through the Federal PKI architecture ... maybe that is what was being thought of.
But another bad chord .... the post goes on to say "A recommendation to make this easier is for all of the issuing certificate authority public key certificates to be stored on the smartcard and available to the OS+applications." The example they give has a signature that is tied through two bridges to the Common Policy. So if I am reading this correctly I need to put the Common Policy Root, the Federal Bridge certificate, the Certipath certificate, the Root of the issuing architecture and the issuing CA certificate all on my card. The idea is that this is what I need to validate the signature. Well yes I need this data but what of revocation data for that chain? So do I put that on there as well - a rhetorical question since we need to get that live - so I need network connectivity. Well if I have network connectivity why not just use the data in the certificates in my trust chain, issuer and it's root, to discover and validate the path that is appropriate based on policy identifiers and business rules?
That was the idea behind the PKITS test - to do the path validation real time using software that did it completely. Do I need this software on my desktop? The answer is no - numerous solutions also provide this capability on server based systems using implementations of SCVP. There are desktop solutions that do it right but it is not the only way.
The other issue that comes up is that the cross certificates that are used between these CAs have shorter lifetimes than the cards and certainly are not in sync with user updates so how do I update these root, issuing and cross certificates on the card?
Yes Adobe you did the right thing by presenting a usability case that truly is needed - we just need to make sure that the system is truly usable in the end-to-end implementation. I think that is where this has fallen short.
- Posted using BlogPress from my iPad
Thursday, March 22, 2012
Thursday, March 15, 2012
Some Thoughts from IDTrust 2012
I spent the last two days at the IDTrust Conference which was held at NIST in Gaithersburg. This conference started about 11 years ago as a PKI centric conference but over the years it has evolved into a broader discussion on identity. Ian Glazer did a great job of laying this out in his presentation early on the first day. This move from an almost pure PKI discussion to a broader identity discussion was seen even at the opening with the initial presentation given by Jeremy Grant, who leads the NSTIC program, and re-enforced the desire to get industry to move ahead with innovative ways to improve the authentication discussion and move towards real implementations.
The discussions held over the two days were great. There was good focus on authentication but also very broad discussions around attributes and their role in improving the confidence levels of the parties involved in transactions. The two days did generate some interesting thoughts, three of which are discussed here.
There appears to be a growing need to handle the lexicon for attributes - this is something that I wrote about quite a while back. The context for my previous discussion was a broker for managing the lexicon - handling the differences between the varying attribute terms and definitions that are being used. This does require considerable cooperation between organizations but a managed central service that is participatory and leverages recognized standards group involvement should address the majority of the interoperability issues.
Identity management appears to be taking on a new scope. When we speak of identity management today we speak of things like registration for authentication credentials, usage of these credentials and maintenance. It does appear though that even within this there is some aspect of attribute management as part of the identity. Now there are some that feel that everything is an attribute, including your name, and I will not be debating that here, but whatever we cover as an attribute we must contextualize those attributes and their reliability, relevance and effectiveness and consider how this may change over time. A simple example is something like address. Even today I can go to a store that has had a record of me from an online purchase and they will still have my address from 4 years ago, even though it is no linger relevant/accurate. Management of these elements of data, including weighting them, is becoming a critical element of the personal data economy. Companies need to know what is current and also what is more likely to be accurate when they access these elements.
A third, and final thought for this post, is the need that comes from the prior two points - how do we effectively manage the attribute lexicon and the data represented within it? One would assume that the data is the users but is the user the only one that can manage it? Do existing attribute brokers/holders such as EQUIFAX and Experian have some level of control or responsibility to handle the weighting or accuracy of the data? Do we provide an easy interface for the user to handle their data and how do we link that to the brokers?
As you can see there was considerable discussion on attributes and attribute management during the sessions and in between them. There was also a lot more data and information and some of the presentations are available on the NIST/OASIS IDTrust 2012 site.
Let's get the discussions going and let's see if we can help move this yardstick forward some.
- Posted using BlogPress from my iPad
The discussions held over the two days were great. There was good focus on authentication but also very broad discussions around attributes and their role in improving the confidence levels of the parties involved in transactions. The two days did generate some interesting thoughts, three of which are discussed here.
There appears to be a growing need to handle the lexicon for attributes - this is something that I wrote about quite a while back. The context for my previous discussion was a broker for managing the lexicon - handling the differences between the varying attribute terms and definitions that are being used. This does require considerable cooperation between organizations but a managed central service that is participatory and leverages recognized standards group involvement should address the majority of the interoperability issues.
Identity management appears to be taking on a new scope. When we speak of identity management today we speak of things like registration for authentication credentials, usage of these credentials and maintenance. It does appear though that even within this there is some aspect of attribute management as part of the identity. Now there are some that feel that everything is an attribute, including your name, and I will not be debating that here, but whatever we cover as an attribute we must contextualize those attributes and their reliability, relevance and effectiveness and consider how this may change over time. A simple example is something like address. Even today I can go to a store that has had a record of me from an online purchase and they will still have my address from 4 years ago, even though it is no linger relevant/accurate. Management of these elements of data, including weighting them, is becoming a critical element of the personal data economy. Companies need to know what is current and also what is more likely to be accurate when they access these elements.
A third, and final thought for this post, is the need that comes from the prior two points - how do we effectively manage the attribute lexicon and the data represented within it? One would assume that the data is the users but is the user the only one that can manage it? Do existing attribute brokers/holders such as EQUIFAX and Experian have some level of control or responsibility to handle the weighting or accuracy of the data? Do we provide an easy interface for the user to handle their data and how do we link that to the brokers?
As you can see there was considerable discussion on attributes and attribute management during the sessions and in between them. There was also a lot more data and information and some of the presentations are available on the NIST/OASIS IDTrust 2012 site.
Let's get the discussions going and let's see if we can help move this yardstick forward some.
- Posted using BlogPress from my iPad
Tuesday, March 6, 2012
Is my smart-phone smart enough?
I read an interesting article this morning that came out of the RSA 2012
conference. Two researchers had found that cell phones leaked data through their transistors which could reveal private keys in use within the running application. One would think after seeing this headline it was a case of poor implementation but these researchers demonstrated this on multiple platforms.
Should we be worried? Is there now an easy way for people to get at your data? The research did show it is achievable to gain access to the keys that are protecting data. An overall successful attack would require multiple elements of course. The attacker needs to get the keys and then gain access to data, either over the air or through a hosted server. Again none of this is impossible but it certainly would be a coordinated attack. So should we be worried? Well if you or your employees are using your phone to protect sensitive data then maybe there is a reason here to start looking at protection mechanisms and procedures that would mitigate some of the risk.
- be aware of your surroundings when you use applications where sensitive data is accessed;
- limit the sensitivity of information that is stored on the device
- start looking to phone vendors that have external validation of their devices or cryptographic implementations whether that be a FIPS style validation or Common Criteria
- have a plan in place to update keys on a regular basis if you need to store sensitive data on your phone
The news of this research is fresh so there is still lots to learn about the risk and mitigations but some of the things above are common sense guidelines that will help to mitigate some of the risk
- Posted using BlogPress from my iPad
conference. Two researchers had found that cell phones leaked data through their transistors which could reveal private keys in use within the running application. One would think after seeing this headline it was a case of poor implementation but these researchers demonstrated this on multiple platforms.
Should we be worried? Is there now an easy way for people to get at your data? The research did show it is achievable to gain access to the keys that are protecting data. An overall successful attack would require multiple elements of course. The attacker needs to get the keys and then gain access to data, either over the air or through a hosted server. Again none of this is impossible but it certainly would be a coordinated attack. So should we be worried? Well if you or your employees are using your phone to protect sensitive data then maybe there is a reason here to start looking at protection mechanisms and procedures that would mitigate some of the risk.
- be aware of your surroundings when you use applications where sensitive data is accessed;
- limit the sensitivity of information that is stored on the device
- start looking to phone vendors that have external validation of their devices or cryptographic implementations whether that be a FIPS style validation or Common Criteria
- have a plan in place to update keys on a regular basis if you need to store sensitive data on your phone
The news of this research is fresh so there is still lots to learn about the risk and mitigations but some of the things above are common sense guidelines that will help to mitigate some of the risk
- Posted using BlogPress from my iPad
Monday, February 27, 2012
Where do I start looking?
This past weekend I was lucky enough to get to hear some great conversations and presentations. It was part of my company's (Entrust) annual conference. The many conversations were with colleagues, partners and customers. The presentations that stood out were from customers, all saying what wonderful things we have done to help them but two in particular stand out that were more general. These two were talks given by Michael Chertoff (former head of DHS) and John Adams (former head of CSE, sort of NSA in Canada for those that need a basic explanation of CSE). Both men have a wonderful breadth of experience and a great view of what is needed to help protect the nations better.
Both men presented an interesting view of things and they certainly have the experience to be able to support their views. Their stories of how things were uncovered are beyond entertaining - the stories truly are frightening when it comes to what could have happened.
Given their experiences in very different environments they did have fairly common views as to what is needed:
- mitigation is key
- layering security is critical to achieve this
- there is no silver bullet
- you cannot protect the network - you must protect the data
- identity is single most valuable asset
- security challenges start with the individual
When one starts to look at these elements it can be broken down to items that apply specifically to businesses but also items that carry across both business and individuals. One important element of that is education. We need to do a better job of educating people with the elements of security that they need to be aware of and address themselves. We do this fairly well in medium to large businesses as to how they protect data with strong passwords and changing them often; keeping security software current; and managing patch updates. What we do not consistently do is to carry those ideas to end users in their homes. End users should not be using the same userid and password on all accounts. Grades of passwords are an effective way of reducing risk. One view that was shared was that 80% of security issues can be addressed by patch and password management. I am not sure that is measurable but certainly we could mitigate a lot of elements with these guidelines.
To re-enforce the above idea, in his discussion former Secretary Chertoff presented an interesting analogy - for some environments security is like an M&M - it has a hard shell but some soft, good eating on the inside. This goes directly to the idea that if users do not effectively manage their security they can create this false sense of security. "I have Microsoft Security Essentials - I am good". This view certainly does not address the password breach issue.
The idea of common userid/passwords across multiple applications at different assurance levels also challenges the implementation of your identity as your most valuable asset. Today too many of us use our email address and password as the login mechanism for a variety of applications, including things like online shopping, access to medical records and other applications. This opens users to phishing attacks that expose more than just access to email accounts but also to this potentially sensitive and possibly damaging information. We need to do a better job at making people aware of these things.
So the title of this post was "Where do I start looking?". Well maybe we need to start with looking at what we do ourselves and how we teach our children and friends about what is important to do when it comes to computer security. I know my kids are aware - are yours?
- Posted using BlogPress from my iPad
Both men presented an interesting view of things and they certainly have the experience to be able to support their views. Their stories of how things were uncovered are beyond entertaining - the stories truly are frightening when it comes to what could have happened.
Given their experiences in very different environments they did have fairly common views as to what is needed:
- mitigation is key
- layering security is critical to achieve this
- there is no silver bullet
- you cannot protect the network - you must protect the data
- identity is single most valuable asset
- security challenges start with the individual
When one starts to look at these elements it can be broken down to items that apply specifically to businesses but also items that carry across both business and individuals. One important element of that is education. We need to do a better job of educating people with the elements of security that they need to be aware of and address themselves. We do this fairly well in medium to large businesses as to how they protect data with strong passwords and changing them often; keeping security software current; and managing patch updates. What we do not consistently do is to carry those ideas to end users in their homes. End users should not be using the same userid and password on all accounts. Grades of passwords are an effective way of reducing risk. One view that was shared was that 80% of security issues can be addressed by patch and password management. I am not sure that is measurable but certainly we could mitigate a lot of elements with these guidelines.
To re-enforce the above idea, in his discussion former Secretary Chertoff presented an interesting analogy - for some environments security is like an M&M - it has a hard shell but some soft, good eating on the inside. This goes directly to the idea that if users do not effectively manage their security they can create this false sense of security. "I have Microsoft Security Essentials - I am good". This view certainly does not address the password breach issue.
The idea of common userid/passwords across multiple applications at different assurance levels also challenges the implementation of your identity as your most valuable asset. Today too many of us use our email address and password as the login mechanism for a variety of applications, including things like online shopping, access to medical records and other applications. This opens users to phishing attacks that expose more than just access to email accounts but also to this potentially sensitive and possibly damaging information. We need to do a better job at making people aware of these things.
So the title of this post was "Where do I start looking?". Well maybe we need to start with looking at what we do ourselves and how we teach our children and friends about what is important to do when it comes to computer security. I know my kids are aware - are yours?
- Posted using BlogPress from my iPad
Location:Ellis St,San Francisco,United States
Monday, January 30, 2012
Some Thoughts Generated at ShmooCon
This past weekend I attended ShmooCon. Depending who you talk to, it is a white hat style conference. I suspect, as with any gathering of 1800 computer security people, you may end up with some black hats and some greys but generally speaking the sessions and discussions that I attended were white hat oriented. It was a good couple of days. For personal reasons I could only be there Friday and Saturday but even that short period of time generated lots of ideas.
Two ideas that stuck with me, even after thinking about them some more, are consumer oriented security thoughts. The first is the idea that not all Certificate Authorities (CAs) are created, or operated, equally. I think this is clearly evident in the issues we have seen with some over the last few years where we have had breaches of administrative accounts either due to the back end implementation or due to poor implementation/operations of user administrative accounts (aka Registration Authorities, RAs).
There are many CAs that are out the that are well operated and that are diligent with external audits and security reviews. These CAs implement policies that are at least as strong as the level of assurance that they deliver to their end customers and these policies are shown to be implemented properly through their external reviews. These CAs are listed in the same security store as other CAs that appear to not have the same level of policies, operations control or external review. In any browser, an Entrust or Verisign CA is treated the same as a DigiNotar, or at least they were before the DigiNotar breach. Is that beneficial to the consumer? There has to be a way to grade these CAs, outside of the EV versus standard certificate ideas. I am thinking something ala the FISMA grading mechanisms used in the US Federal government. In the FISMA grading system agencies are penalized for gaps, the bigger the gap in the operations versus policy, the bigger the hit. The grading then looks like the Green, Yellow, Red rating system. If this style of system was implemented in conjunction with Browser vendors the browser could allow a user to define a tolerance level - I will accept yellow and greens without warning, unless there is another issue, and I want to see warnings for red or block red all together. The variations between the levels could be worked through the CA Browser Forum and the determination of what triggers a downgrade or what is needed to bump a CA level back up.
The other thought is in a similar vein. Today when I authorize app access, whether on my phone or through some form of account connect, think Facebook Connect as an example, I see what the application is accessing and in some scenarios I have the option to be selective on if I want the application to have all the privileges it is asking for. For example - do I want the app to post on my Facebook Wall? Or, Do I want the app to have default access to my GPS location? This sort of flexibility may be lost on some but I do appreciate it as I often wonder why an app requires certain access. Now grant it, not all application platforms provide this flexibility but I see more and more doing this. What is interesting is when I access a website with Java code I do not get the same level of control. I can decide to only trust signed code but given the issue I described above is that enough? Do I want my code signed by a CA that I would not normally trust? Since Windows update dumps the full Root trust list to me and I have to manually go through and clean it there seems to be an opportunity here to do some better refinement. Again this would require browser cooperation but the end result could be powerful.
So the idea is two fold: "encourage" app developers to identify, in a standards way, likely in Metadata, the permissions that the app requires. With this definition lets give the user the option of choosing how to operate. Again the browser vendors could default settings but give the user the option of choosing whether he wants to see the data and how they want to react to the data. Settings to allow "application operations for JAVA" for example. If the code has permissions meta data then display that and let the user choose. If not then notify the user of the CA level (see above) that signed the data and make them aware of risk.
I am the first one to realize that the weakness in most of transactions is the end user but I believe that these types of implementations would increase awareness as they are already seeing elements of these in other areas. Of course this will require cooperation between developers and browser companies to implement and likely not a tomorrow thing but I believe something that should be thought about in a broader forum.
Two ideas that stuck with me, even after thinking about them some more, are consumer oriented security thoughts. The first is the idea that not all Certificate Authorities (CAs) are created, or operated, equally. I think this is clearly evident in the issues we have seen with some over the last few years where we have had breaches of administrative accounts either due to the back end implementation or due to poor implementation/operations of user administrative accounts (aka Registration Authorities, RAs).
There are many CAs that are out the that are well operated and that are diligent with external audits and security reviews. These CAs implement policies that are at least as strong as the level of assurance that they deliver to their end customers and these policies are shown to be implemented properly through their external reviews. These CAs are listed in the same security store as other CAs that appear to not have the same level of policies, operations control or external review. In any browser, an Entrust or Verisign CA is treated the same as a DigiNotar, or at least they were before the DigiNotar breach. Is that beneficial to the consumer? There has to be a way to grade these CAs, outside of the EV versus standard certificate ideas. I am thinking something ala the FISMA grading mechanisms used in the US Federal government. In the FISMA grading system agencies are penalized for gaps, the bigger the gap in the operations versus policy, the bigger the hit. The grading then looks like the Green, Yellow, Red rating system. If this style of system was implemented in conjunction with Browser vendors the browser could allow a user to define a tolerance level - I will accept yellow and greens without warning, unless there is another issue, and I want to see warnings for red or block red all together. The variations between the levels could be worked through the CA Browser Forum and the determination of what triggers a downgrade or what is needed to bump a CA level back up.
The other thought is in a similar vein. Today when I authorize app access, whether on my phone or through some form of account connect, think Facebook Connect as an example, I see what the application is accessing and in some scenarios I have the option to be selective on if I want the application to have all the privileges it is asking for. For example - do I want the app to post on my Facebook Wall? Or, Do I want the app to have default access to my GPS location? This sort of flexibility may be lost on some but I do appreciate it as I often wonder why an app requires certain access. Now grant it, not all application platforms provide this flexibility but I see more and more doing this. What is interesting is when I access a website with Java code I do not get the same level of control. I can decide to only trust signed code but given the issue I described above is that enough? Do I want my code signed by a CA that I would not normally trust? Since Windows update dumps the full Root trust list to me and I have to manually go through and clean it there seems to be an opportunity here to do some better refinement. Again this would require browser cooperation but the end result could be powerful.
So the idea is two fold: "encourage" app developers to identify, in a standards way, likely in Metadata, the permissions that the app requires. With this definition lets give the user the option of choosing how to operate. Again the browser vendors could default settings but give the user the option of choosing whether he wants to see the data and how they want to react to the data. Settings to allow "application operations for JAVA" for example. If the code has permissions meta data then display that and let the user choose. If not then notify the user of the CA level (see above) that signed the data and make them aware of risk.
I am the first one to realize that the weakness in most of transactions is the end user but I believe that these types of implementations would increase awareness as they are already seeing elements of these in other areas. Of course this will require cooperation between developers and browser companies to implement and likely not a tomorrow thing but I believe something that should be thought about in a broader forum.
Tuesday, January 17, 2012
Sykipot Update
As I mentioned in my last post - one of my concerns was the possibility that a hacker could leverage the PIN access and the card update capability of the ActivClient to introduce malware on the card. After some investigation it appears that with the use of the Global Platform implementation it would be an extremely complex feat to execute. I do not believe it is impossible but the level of effort does not appear to have been taken and it would only be capable of happening during an actual card update which in most cases would be CMS initiated. There does not appear to be anything the data that has been released to indicate that there is a trigger for the action - so maybe one less concern.
Friday, January 13, 2012
Is this Sykipot something new?
Undoubtedly you have all seen the news of the alleged attack via Sykipot against US government smartcards. Of course the press has taken ahold of this with all of its usual gusto but is this really something new?
Well yes there are new elements to it - it appears to be the first Sykipot variant that appears to have specifically targeted a specific client and middleware to access smartcards for the purpose of utilizing the private keys for access to data. That being said the actually attack vector is not new and has been looked at for many years. This attack has the same sort of path as any man-in-the-browser style attack - deliver command and control elements to the target; install a key logger to capture and; once having determined that the target is viable then deliver the elements necessary to execute a complete attack. The major issue here is that fundamentally this was once again initiated through spear-phishing to deliver the required infrastructure to build the attack and possibly leverage it.
We are once again facing a massive push against a technology that fundamentally is not at fault here. If we look back at some of the attacks like this that occurred last year - it was not the technology but the implementation and the processes around the technology that are being leveraged to attack. It fundamentally did not matter what the underlying technology was. This Sykipot attack, ten years ago, would have been a key logger capturing userid and passwords, and just as likely could have been that today for many systems. However because it is smartcards it is now big news.
So is there really an issue - well quite possibly yes - and it could be big. Yes it is a problem that the card can be used when inserted without the user knowing it is being used - this is of course a major issue. There is however a potentially larger issue and the outcome of the investigations will determine if it is a real issue or not. The ActivClient does have a variant that is deployed to allow the local user to update their card. If in fact this Sykipot variant is hijacking the interaction with the ActivClient is it possible that the card can then be infected with malware? The threat of malware on the card is likely the worse case scenario. I know of no virus software that scans cards on insertion and it could be possible that this malware could be transmitted to devices via the contact and contact-less interface which would mean delivery to many platforms, possibly without knowledge. Of course right now this is speculation but hopefully one of the paths that is being investigated.
It will be interesting to see what comes out of the investigations and what gets publicized. For this interested in getting a base set of info on the attack check out the Alienvault article.
- Posted using BlogPress from my iPad
Well yes there are new elements to it - it appears to be the first Sykipot variant that appears to have specifically targeted a specific client and middleware to access smartcards for the purpose of utilizing the private keys for access to data. That being said the actually attack vector is not new and has been looked at for many years. This attack has the same sort of path as any man-in-the-browser style attack - deliver command and control elements to the target; install a key logger to capture and; once having determined that the target is viable then deliver the elements necessary to execute a complete attack. The major issue here is that fundamentally this was once again initiated through spear-phishing to deliver the required infrastructure to build the attack and possibly leverage it.
We are once again facing a massive push against a technology that fundamentally is not at fault here. If we look back at some of the attacks like this that occurred last year - it was not the technology but the implementation and the processes around the technology that are being leveraged to attack. It fundamentally did not matter what the underlying technology was. This Sykipot attack, ten years ago, would have been a key logger capturing userid and passwords, and just as likely could have been that today for many systems. However because it is smartcards it is now big news.
So is there really an issue - well quite possibly yes - and it could be big. Yes it is a problem that the card can be used when inserted without the user knowing it is being used - this is of course a major issue. There is however a potentially larger issue and the outcome of the investigations will determine if it is a real issue or not. The ActivClient does have a variant that is deployed to allow the local user to update their card. If in fact this Sykipot variant is hijacking the interaction with the ActivClient is it possible that the card can then be infected with malware? The threat of malware on the card is likely the worse case scenario. I know of no virus software that scans cards on insertion and it could be possible that this malware could be transmitted to devices via the contact and contact-less interface which would mean delivery to many platforms, possibly without knowledge. Of course right now this is speculation but hopefully one of the paths that is being investigated.
It will be interesting to see what comes out of the investigations and what gets publicized. For this interested in getting a base set of info on the attack check out the Alienvault article.
- Posted using BlogPress from my iPad
Subscribe to:
Posts (Atom)