Adobe Moving Forward with Smartcard Usage ... or is it moving forward?

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

Is Authenticating to the Cloud different than anything else?

I was reading an interesting article the other day on a new Government Cloud service being offered by Amazon. Security advances and budgetary pressures draw agencies to cloud - Nextgov: This to me raised a number of thoughts including the cost of compliance for Amazon to maintain the system to meet some very broad and detailed government requirements. Now do not get me wrong, I think that Amazon has the capability to do this, the question becomes is there the long term desire to maintain things that the government will require of them. The flip side of this is that it may encourage the government agencies to rethink how it looks at maintaining systems and may in turn help them to reduce some of their costs internally as well.

The other thought I had was one of protecting access to the data. The federal agencies have broadly moved to smart card based authentication systems and are now looking at how to enhance that with attribute based authorization using architectures like BAE (Backend Attribute Exchange). I wonder how Amazon intends to leverage the authentication infrastructures that have been put in place. Does the Amazon offering now allow extension of the user platform beyond the traditional desktop to tablets and smartphones, both of which have become very relevant in the government market? How will Amazon handle the enhanced checking of credentials and interoperation with these systems? How open to the acceptable government profiles for SAML, OpenID and Kantara will they be? There are lots of questions here and dependent on which requirements the government has been testing the Amazon service against these may already be in the forefront or these may start to appear as people use the service.

Of course there is no lack of technology that will enhance the architecture - systems that provide for multiple authentication device types, which may be required dependent on the resource accessed, combined with the ability to roll out strong authentication credentials to smartphones or tablets (whether PKI, OTP or others), along with a variety of smart card/chip capabilities that can use various communication technologies certainly opens the field of use.

These are all things we are working with today and implementing for a broad audience. The technologies are there, the systems just need to leverage them appropriately.



- Posted using BlogPress from my iPad

What is Security?

I read an interesting article this morning on mobile banking. Now do not get me wrong - I am looking forward to mobile banking but the article raised another question in my mind - what exactly is security?

There are lots of people around the world using mobile payments today. With the advent of Google Wallet, Serve, VISA Wallet, ISIS and others combined with the rollout of NFC enabled phones this will only grow. Of course as this begins to grow these companies will focus their attention on making sure that their systems cannot be breached. The last thing they need is someone to pay for something they did not buy or to have the bitCoins situation of suspected account breaches occur. The use of strong authentication and fraud detection improves the security posture and the retailers themselves are bound to protecting data to maintain their agreements with payment systems such as VISA and MasterCard, so one would say the system should be as secure as the payment systems in use today.

But is it truly a secure system? The WSJ article discusses one of the big concerns that came out of the NSTIC privacy conference - reuse of data. What information is the payment system I am using or the retailer I am dealing with collecting? How are they using this? If a retailer collects my cell phone number as part of the authentication process can they keep that data tied to what I bought and the next time I walk near their store text me a coupon? That of course is the most minor case here.

This is yet another demonstration of the need for privacy controls at the device and within the relying party. At the device it should come as a form of an information or attribute release option, defaulted for some transaction types and interactive for others. At the relying party, in this case retailer, some form of opt-in mechanism for data handling. Maybe I want the coupons - but give me the option.

So is a system secure if the user does not have control of their privacy or is it good enough to say that the system will not have a serious breach? It is a interesting question.

As can be seen there are still lots of areas of specifications that need to happen. Are these areas for policy definition within something like PCI or are the areas here something that need to be included in legislative discussions? Lots to be done and how it happens, I believe, will determine how successful these systems are.

- Posted using BlogPress from my iPad

Report from NSTIC Privacy at MIT

I have attended the initial two NSTIC conferences and I think I can safely say that things are ..... interesting. My first comment is that it is quite obvious that there is still a lot of work to be done. I firmly believe that in the governance and privacy areas there is one big thing that needs to be done and that is to take what has been accomplished in other areas and map those to see where there is intersection and then see if that is something that will be useful for NSTIC. I say this because there are lots of good things going on in a number of areas but right now I think trying to take each one of those and to map to NSTIC or to see which piece is useful may be overwhelming. I hope that as responses to the NOI come in that a process like this will help to ease the burden.

The conference itself was thought provoking. Some ideas that struck me were ideas of data ownership and pseudonymity versus anonymity. There were many others but these two struck me in particular.

On the data ownership side there was much discussion on data ownership. Certainly it is easier to define ownership of some elements of data including things like credit card numbers, social security numbers, birthdate, address, weight, height etc .... but what of other types of identifying data? When I buy something online at apple.com is the fact that I bought something make that my data element or does it belong to Apple? Certainly Apple needs to know who to charge and what and where to ship but outside of that, once the transaction is complete, do they need to keep that data if I do not want them to? Should they be allowed to tell Verizon that I just bought a 3G iPad 2 with a Verizon chip in it? These "data breadcrumbs" are left by all kinds of transactions and the question of ownership is interesting.

But of course it is not just ownership - once I have ownership how do I protect that data from improper use or for that matter any use that I do not want? This is an interesting challenge in terms of privacy and in the process does it step on things like tracking (web tracking being looked at legislatively today)? Does it also step on business model? Experian, Transunion and others keep data on me that they use to provide market targets to other service and product providers. What happens to these entities and the downstream providers, who use the information, if we change how those breadcrumbs get picked up?

The other interesting data point was the pseudonymity versus anonymity thoughts. For those of us that believe we can be anonymous on the Internet I present an excerpt from an LA Times blog on the possible exposing of LulzSec. "The A-Team said LulzSec's members were a product of the hacking culture found on the Website 4chan, which is rooted in anonymity, making some feel invincible. .... "The Internet by definition is not anonymous," the group said. "Computers have to have attribution. If you trace something back far enough you can find its origins.""

So do we accept that we will at best be pseudonymous? Does that lead to multiple identities or multiple personae within a single identity? In either case it becomes critical that we prevent linkage between these unless that linkage is driven by the identity owner. This idea is one I will be thinking about some more - it is definitely interesting.

There were many more great ideas shared and I would encourage anyone with interest to visit the NIST NSTIC site to follow the updates.

- Posted using BlogPress from my iPad

Re-application of Technology

As I was thinking about the upcoming NSTIC Privacy Conference my mind wandered to some of the technical challenges that exist. Some of these are things that we have been discussing for some time and are directly related to privacy. One of the core ideas is that in our online lives we have different degrees of relationships with other entities. Some of these relationships require a high degree of assurance as to who I am, for example, accessing my health records online, others do not require a high degree of assurance (commenting on blogs is one of them). That being said the question becomes how do I maintain a single identity but use it differently in different places?

There are a couple of technical solutions that are out there today that are being discussed:

• Backend Attribute Exchange (BAE) leverages SAML 2.0 and a cooperative architecture to build a system whereby a relying party can request further information about an authenticated entity using a set of standard protocols. This system works very well in an environment like one of first responders where the community is well defined and the sources of attribute information are well recognized. I also think it can be extended to a more general use but a broader infrastructure for identifying Attribute Providers needs to be architected and a mechanism for predefined release needs to be implemented within these. I do believe all the pieces are there and I know some of this work is ongoing so we may not be that far away.
• uProve is driven largely by Micrsosoft but there are a number of open working groups including one on Claims Agents that are looking to open source variants of elements of the system. Teh basic tenet of uProve, from a architecture perspective, is not that different than BAE. Grant it the underlying technology is very different but the architecture of a relying party, communicating with an end entity for authentication and then using a third party to validate claims is not that different than what BAE is achieving. 

There is a third one that comes to mind and it relates to the idea of re-application of technology. ePassport systems are based upon either Basic Access Control (BAC) or Extended Access Control (EAC) mechanisms for access to information on the ePassport. At Entrust, where I work, we have implemented both types of solutions in multiple countries and have been involved in the standards work around ePassports for a number of years. As the BAE and uProve technologies have come to surface I began to think about how EAC has the same basics in terms of architecture. The EAC architecture is more closed today due to the application but with the ongoing definition of EAC 2.0 there is a lot more similarities in terms of architecture. Can EAC 2.0 be even further extended such that its protocols extend beyond the chip-reader communication set to reuse the ideas there to allow for extension into chip-relying party in general? Does this provide the end entity with greater control in terms of information release and do so in a self contained environment? Today information release through uProve and BAE have release notification at the attribute service but could EAC bring that to teh credential holder in a self contained way.

I am planning to explore this a bot more over the next two days at the NSTIC conference in Cambridge so look for a follow-up.

Why PIV-I?

I wanted to followup on the discussion of PIV-I that I started a couple of weeks back. That discussion centered around what is PIV-I. As is the case the "what" has to be paired with a "why". Over the last couple of weeks I have also brought up a couple of other issues that tie in here that can be summarized with "authentication architectures".

The last few months have seen a significant proliferation of attacks against authentication systems: RSA SecurID, a defense contractor having their Active Directory administration services breached; and the Comodo attack against an administrative function. These attacks, and more, were intended to achieve one thing and that is to be able to get deeper into systems than a normal attack would and to potentially extend the attack reach outside of the initial target.

So how does this play to PIV-I?

PIV-I does  a number of things: it defines a standard issuance process; it defines a standard token; and it defines a standard token interface. The PIV-I specification allows organizations to readily see that another organizations have implemented an authentication mechanism that is measurable. Once you know that the mechanism is measurable then you can decide how it meets your requirements so you can decide if you can trust these credentials, and for what purpose. A good example of this is within the US Government agencies looking to PIV-I as a way to be able to easily work with external parties, contractors, suppliers, partners and other governments like State and Local. An example of this happening is that DOD has created a list of commercial SSPs that issue PIV and PIV-I credentials that can be trusted within DOD. So there is a business reason to use PIV-I, a strong mechanism to allow for digital interoperability at a high degree of assurance.

There is also a business reason for PIV-I based on the above mentioned attacks. A PIV-I token is a FIPS validated credential with strong protection mechanisms. Too many wrong passwords and the token is no longer usable. Private keys cannot leave the card. It is a PIN protected device; and has a biometric capability for additional assurance requirements. On top of these the credential is issued through a process that is well defined, requires in person proofing, and is separate from the relying party application. This last piece is the important element as it provides a safety barrier in the case of attack against the authentication system, as discussed in the last post. Another good read on the subject can be found here.

So PIV-I is an authentication mechanism that provides a well defined process for issuance, a strong credential  for identity (physically and logically) and mitigates some of the risk factors that were in place with the attacks against authentication systems that have happened over the last many months.

Next will be a discussion on using PIV-I in a solutions architecture.

APT and Layered Authentication

I was recently speaking with someone about their infrastructure and an issue they were addressing. Their infrastructure is based around Active Directory. It is a standard implementation that uses AD to identify end entities, grant privilege and to push policy. The issue is that they are faced with an Advanced Persistent Threat against this existing AD implementation. The question becomes how does one move from this existing infrastructure to a new one while ensuring that they can safely port the existing end entity population (machines and persons) and to ensure that they implement a strategy that mitigates the risk of the ongoing and future APTs.

It seemed to me that the initial strategy has to be one around the segregation of the authentication infrastructure. In a traditional layered security approach we speak of separation of duty, roles and in some cases networks but infrequently do I see people look at the authentication infrastructure as a separate element - it normally is imbedded into some other element - usually preceded by comments like "well Microsoft gives me a CA imbedded in AD". no knock against Microsoft but we need to be careful of architectural implementations.

The authentication infrastructure is a key component of usability but also of defense. Knowing who is accessing a resource is critical and in the case of an APT even more so as the traditional ways to protect a resource may already be compromised. There was a very good example of this within the last year when a major technology/defense firm had their AD compromised. In the process of that compromise the attacker was able to act as a administrator for the certificate authority that was part of the AD implementation and was able to issue credentials that allowed broader access and possibly to a wider audience.

It is becoming critical in light of these persistent attacks that additional precautions be taken. Layering the authentication infrastructure is one element of this that allows for migration of the core elements with less impact on end entity credentials. Similarly if the authentication infrastructure becomes compromised, such as the RSA breach, then you can also take a layered approach to credential replacement. Although this is more challenging if you do not know how deep the attack became after the credential breach but this is another reason to stress the importance of the authentication infrastructure. One step beyond that would be to look at layers of credentials within your infrastructure that would allow levels of access to resources based upon risk and type of credential presented .... but that is another topic.


- Posted using BlogPress from my iPad

What is PIV-I?

I have been involved with credentialing in the Federal Government for many years, coming on multiple decades to be honest, and it has been an interesting ride. Over the last few years there has been a substantial change, starting with the signing of HSPD-12 in 2004. What HSPD-12 did was to codify credential issuance within the Federal Government. HSPD-12 brought in not just a technical specification but also a process specification. The combination of these two elements was intended to address the differences between agencies issuance processes as well as allowing interoperability of credentials, at a logical and physical level, between agencies.

As part of the extended process the Federal working groups within the Federal Identity, Credential and Access Management community also developed a set of requirements for organizations external to the Federal Government to create credentials that were based upon a well defined set of standards both from a technical perspective as well as from a issuance perspective.

So what are the differences between a PIV card and a PIV-I card? I hate to give a bulleted list but I am not sure how else to do it so here goes: (Note the left side will always be PIV and the right PIV-I)

• Identity Verification: While both PIV and PIV-I strongly authenticate individuals there is a slightly higher requirement for PIV. The PIV IV process requires that the end entity have a National Agency Check with Inquiries (NACI). 
• 10 vs 2: For PIV cards, ten fingerprints are collected, where possible, while for PIV-I only two are required to be collected
• FASC-N vs UUID: These are identifiers for the end entity normally used as part of the access control decision for physical access. It is possible that the government will move towards the UUID but for now it is FASC-N. The structure does allow for quick differentiation between a PIV and PIV-I card at a PACS system.
• Common Policy vs FBCA mapping: From a logical perspective the trust anchor for PIV is the Federal PKI Common Policy Root. For PIV-I the trust anchor is the issuers root but the issuers policy must be mapped to the Federal Bridge CA. This is demonstrated in the different OIDS used in the certificates in the cards. The intent here is to allow users under the Common Policy can trust users of PIV-I cards through the linkage at the FBCA.
• Content Signing: Both PIV and PIV-I cards contain signed objects. These objects are signed using certificates that carry specific indicators that they be used only for content signing. The identifiers used are different for PIV and PIV-I and therefore it provides another way to differentiate the card.
• Physical Layout: A PIV-I card MUST look different than a PIV card. 

So as you can see there are differences but the intent is to make the PIV-I card usable within an organization and to also allow it to interoperate with other organizations, both physically and logically. The publication of the specifications, with a validation process, allows application vendors to build systems, logical and physical, to use the cards and also allows relying parties to be able to determine their policy on use of PIV-I cards.

So who should think about PIV-I and why? I will leave that to another day.

Google Authenticator

Yesterday I sat in on the Interagency Advisory Board meeting. The first topic of conversation was the Google two factor solution which made me think that I should write a brief piece on my experience with it as I have used it for a few months now on my personal Google account.


The widely available two factor solution is based upon an OATH implementation. It supports both HMAC-based (HOTP) and Time-based (TOTP) one-time password algorithms. Today it has two major components - apps including an Android app, a Blackberry app and a IOS app and; a PAM module that can add two factor authentication to PAM-enabled applications. I use the Android app which allows me to use counter or time based OTP. The photo is of the iPad (IOS) app.

Setting up two factor can be a bit of an issue - but only from a time perspective. You need to have the app downloaded so you can get going right away and then you need to think about your applications where you are using your Google identity as your login credential. In some cases these apps are not PAM enabled so you will be generating application specific random passwords for these accounts. For example - on my Apple TV I access my YouTube account but since it is not PAM enabled I generate a random password and then use this to register the account. These random passwords are 16 character passwords generated by the application so changing them as frequently as I change others is not needed and especially since it is YouTube. In my case because of the mix of applications and devices, Gmail on my iPad and on my Android for example, I have 20 apps registered for these random passwords.

In terms of use - the passwords for non-PAM apps are not an issue as they are configured to not require re-entry every time. For the PAM-enabled apps it is as easy as starting up the Google Authenticator app on my phone and I am more likely to have that with me than any other hardware based token. If for some reason I do not have my phone, and I REALLY need to access the app then I have the option of using one of ten, one time use, pre-generated backup codes or I can use voice based OTP where I can have them call my pre-registered number. I have never had to do either of these as I always have my phone.

So far I would say it has been a good experience and I am on the verge of converting my work-related account as well.

Where are things headed? Well from the conversation yesterday it does sound like Google is looking at alternatives for authentication besides the Authenticator app but I will leave that conversation for another day.


- Posted using BlogPress from my iPad