For Archival Purposes

You probably could’ve guessed that this blog has been retired since VeriSign acquired TrustBearer in April of this year.  We’ve also retired the domain, but we still get a fair amount of traffic here, so I’m moving this blog back to it’s original WordPress URL,

Yes, this will break some inbound links, but at least the content will still be searchable. Thanks to everyone who has read and contributed over the years.


The Challenges and Pleasures of Working for a Growing Software Company

My name is Rachel Steger, Office Manager for TrustBearer.  As a newcomer to the world of start-ups and software development last summer, my first six months with TrustBearer have been hugely enlightening.  With a background only in medium to large-sized corporations, I have found that I had a few misconceptions about what my professional life would look like once employed by an early-stage start-up company.  I never realized how non-existent bureaucracy could be within a hugely successful company, or how much of a relief it would be to not have to wear a suit and heels for my first day in the office.

TrustBearer life is about as casual as it gets – which is pretty typical for a small software company, from what I understand.  We all appreciate the flexibility of tracking our own hours and coming to work in shorts in the summer, if we want to.  Work hours are often long, but we all have a good time while we’re here.

The casual environment should not be confused for a slow-paced work day, however, or a lack of professionalism.   Work pours in and we pour it back out.  Projects show up with short deadlines, customers on other continents need immediate attention and assistance, and our office in D.C. keeps us hopping with an ever-growing list of government sales.

As Office Manager, I’ve been tasked with adding structure to this small company as it quickly outgrows its start-up status – as well as just about anything else that needs done (OK, so we’re not quite out of the start-up phase yet).  I would have to say that one of the joys of my job is that there are very few of us who have to come to consensus on how this should be done, which simplifies the process immensely.  The challenge has been to figure out how to grow without killing the great environment that has been built here over the past five years — how to add policies and procedures without completely annihilating the freedoms that we all appreciate on a daily basis.

When I joined the company last year, I didn’t quite anticipate the types of clients that a company of a dozen people would be working with on a daily basis – large enterprise customers and government clients such as SSA, FAA, Air Force, and others, to name a few.  As the smallest company in the smart card/middleware market, it has been exciting to see us build important relationships with large-scale companies, and to understand that even a small company in Fort Wayne, Indiana can make a world-wide impact in the security industry.

2009 was a great year for TrustBearer!  For the first time we have formal, dedicated 24-7 customer support; we helped rollout a healthcare product and obtained an exclusive American Hospital Association (AHA) endorsement; we expanded to a second location in downtown Washington, D.C.; we made an appearance on the GSA schedule; and we forged exciting partnerships with companies from all over the world.  It will be interesting to see what 2010 looks like.

Stay tuned…..

RSA 2010

If you are going to be at the RSA Conference this year, we look forward to talking with you.

The RSA Security Expo
Monday March 1st – Thursday March 4th

VeriSign Booth #1717
(see map below)

San Francisco, CA
Moscone Center

This year, we’ve worked with VeriSign to integrate TrustBearer’s technology with VeriSign’s Managed PKI (MPKI) product, and we’ll be showing demos of this joint solution at the VeriSign booth.

We’ll also be showing our updated OpenID and SAML identity provider, which now allows users to register their computer with VeriSign MPKI. Similarly, users with PIV and CAC smart cards, and many other security devices, can use their credential for multi-factor authentication to web applications like Google Apps, Salesforce, and Basecamp.

If you would like to schedule a meeting with us during the conference, send us an email:

To learn what we are up to during the conference, follow us on Twitter: @trustbearer.

Showcase with EXTENSION at HIMSS 2010

We’ll be at HIMSS 2010 next week with EXTENSION Inc., showing the EXTENSION HealthID product:

HIMSS 2010
Monday March 1st – Thursday March 4th

Booth #5955
Atlanta, Georgia World Congress Centre

Show Hours Are:

  • Monday, March 1, 12:30 pm – 5:30 pm
  • Tuesday, March 2, 10:00 am – 1:00 pm and 2:30 pm – 5:30 pm
  • Wednesday, March 3, 10:00 am – 1:00 pm and 2:30 pm – 5:30 pm

If you are at HIMSS this year, we’ll look forward to talking with you.

The Use and Abuse of Identifiers

In my line of work at TrustBearer, we work with a number of different identifiers, be they OpenID URIs, usernames, or email addresses. In this way, I probably don’t have an realistic appreciation for how most people using such identifiers think and feel about their email addresses,  usernames, or twitter handles. And for this reason, I’ve found the research of doctoral student Ben Gross (@bengross) quite interesting and valuable.

In short, Gross has found that people have rather personal feelings about the identifiers that they are assigned and used, and they have a hard time using these identifiers how they would like, or how their employer expects them to.

Much of this research was discussed in a recent presentation at BayChi San Francisco (a chapter of the ACM Special Interest Group on Computer-Human Interaction).

Gross’s research involved talking with people in two types of companies, financial and creative, about the identifiers they use at work and in their personal life. His findings help explain why people often accidentally (and purposely) misuse identity systems:

  • Most people are managing a few email addresses, dozens of usernames and passwords, and several other identifiers, and they make very complex social decisions about how and why they use these identifiers.
  • The people Gross talked with wanted their identifiers to be their own name—even John Smith— or something meaningful and easy-to-remember.
  • People want to use personal and other identifiers at work; if they have trouble with identity and communications  systems at work, they use personal ones, e.g. their Hotmail.
  • Everyday use of identifiers can involve technical concepts, which are foreign to most users.
  • Some people Gross talked with started using an identifier in a certain way, but they don’t remember the initial reason or preference for this.
  • People usually don’t understand and often dislike and avoid identity system policies and rules.

Gross also has looked into what people know and don’t know about their privacy related to identifiers. Like something you are or something you have, the things that you are assigned, such as a IP address, a location, or a web cookie, act as identifiers. And it is these identifiers that are most often used on the web for tracking people’s behavior and information (See Kim Cameron’s recent post about browser fingerprints). In this case, Gross looks forward to better applications and tools that allow average web users to control their privacy and for more transparent policies with regard to what information companies or other entities store and track.

Gross’ dissertation and published writings are available on his website. He has written about OpenID and OAuth on his blog at The Messaging News.

Software Testing at TrustBearer

Hello, I’m Charles and I’m the new Quality Engineer at TrustBearer.  TrustBearer brought me on keep the company on track to meet its quality goals. Some of these goals were already being implemented when I got here: unit tests, code reviews, good defect tracking, code documentation. For my part, I tend to focus on system level testing, including functional and non-functional testing (security, performance, etc.), as well as developing a more solid and repeatable testing process. With this in mind, I’ll going to discuss the testing and quality assurance work we do at TrustBearer to ensure that our products work well and are secure. I’ll also focus on some of my personal philosophy with regards to testing.

My philosophy boils down to the idea that no program can be fully tested, and that a tester, or testing team, should focus on the ROI for their time. A lot of this philosophy has been developed from discussions with and readings from other professionals in the field such as Cem Kaner, James Bach, and Michael Kelly, including the idea of Context-Driven Testing. Some of my ideas also come from one or both of the organizations I belong to, the Association for Software Testing (AST) and the Indianapolis Workshops on Software Testing (IWST).

Now, how does this philosophy apply to TrustBearer products? Well, if we look at our website at the TrustBearer Desktop page, we list our compatibility for various smart cards, OSes, and mention other technologies we are compatible with. Just looking at the page tells me that there is a good number of combinations of OSes, browsers, smart cards, and mail programs that need to be tested, and that ignores any external factors (other USB devices that are used by the customer causing problems with our system, for an example).

So if it’s impractical to test everything all of the time, what is tested? There is no one correct answer, however, a good tactic to take focuses on defining the problem space. For me, this involves finding the typical configurations first. When I say a typical configuration for TrustBearer products, I mean this in regards to what our software interacts with. We can never fully replicate what our customers will have in terms of hardware and software, but we can have a reasonable approximation. For instance, if most of our customers are using PIV cards with Windows 7 as their OS, Firefox 3.5.6 as their web browser, and Outlook 2007 as their mail program, then my tests are run primarily using that as a base configuration.

Another good way to focus what is tested is to look at what features are used the most, and in what ways. For a good example of this, our software products facilitate the use of hardware and software tokens for things like windows logon, email signing and encryption, signing Word and PDF documents, as well as interacting with various websites. While we test all of these features, initial testing would focus on what our customers typically used our software for most.

Another generally good method of testing is focusing on high-risk areas. For some applications, this might be the billing system, or the login system, neither of which you want to find any serious defects in). For TrustBearer, this focus tends to fall on security testing. For instance, sometimes we develop web pages for customers that work with our TrustBearer Live Plugin, and we run tests simulating SQL Injection, phishing, and man-in-the-middle attacks to make sure that our customer’s data can’t be exposed to anyone untrustworthy.

Using these techniques as a base, we go on to test more and more features and platform combinations. The goal being that we have confidence that any bugs we have not found are minor, obscure, and will not cause problems for our customers. As with everything else in software, this is never a finished process, but with a good philosophy and a dedicated team, quality improves with every revision.

While that isn’t all there is to testing, I hope that the above gives you a little glimpse into the process, and hopefully I’ll be able to share more of the process of testing, tools we use, and how we determine when we’re ‘finished’.

– Charles

First Impressions of ISO/IEC 24727

Results of the Google search for ISO/IEC 24727** 6 Jan 2010 Update:  The official presentations are now available from NIST.

Today, googling for ISO/IEC 24727 returns ~5000 results.  The first four are links to purchase the standard specifications from either the ISO or IEC webstore.  The fifth, ISO/IEC 24727 – A Future Standard for Smart Card Middleware, looked like a simple description of the standard, maybe distilled for a broader audience…  But, it’s actually a paper about the standard on sale for $25! Perhaps this lack of free information was part of the reason NIST decided to hold a workshop all about the standard this past week.

I attended NIST’s Tutorial Workshop on ISO/IEC 24727 (Identification Cards – Integrated Circuit Card Programming Interfaces).  It lasted a few days and it covered a ton of information about this 6-part standard.  The workshop speakers included several editors of the standard, including Tim Jurgensen, Mike Neumann and Alex Gagel, as well as representatives from NIST who have also been working with 24727 in various capacities: Terry Schwarzhoff, Bill MacGregor, and Sal Francomacaro.  Ketan Mehta & Hung Dang from Booz Allen Hamilton and Alexander Winnen from Giesecke & Devrient gave technical demonstrations of the standard in-action.  Alex Gagel also detailed the first substantial use of the standard for the Queensland, AUS Driver license.

Outside of NIST, it seems that there has been little involvement from United States companies in developing 24727.  Perhaps that is part of the reason why there is not a ton of information available online.  This post explores 24727 from a U.S. smart card standards perspective.  If you’re familiar with CAC and PIV, but are just hearing about 24727, I hope this helps.

Some Background – HSPD-12 & PIV

ISO/IEC 24272 is a bold attempt to make identity credentials (such as smart cards) and the applications that consume those credentials much more interoperable than they are today.  Wait, isn’t that what PIV was supposed to do? Sort of, but 24727 goes much further in its interoperability goals.  On the technical interoperability side, PIV defined a smart card edge (API), data model (to store the cardholder’s name, ID#, photograph, etc.), and required cryptographic capabilities.  FIPS 201 (Titled Personal Identity Verification of Federal Employees and Contractors or “PIV” for short) tackled much more than just the technical specifications of the smart card.  It also defined the physical card look and feel of the card, standardized the identity vetting procedures, and provided use cases for physical and logical access.

The goals of 24727 are slightly different than the U.S. Government’s goals with PIV.  FIPS 201 / PIV was created in response to HSPD-12 – a request from former President G.W. Bush to create an identity standard for all federal employees and contractors.  NIST answered the call and developed the FIPS 201 specification in 6 months – a very short amount of time for a standard encompassing many identity concepts.  PIV defined a single smart card standard that enabled many different hardware and software manufacturers to create compatible products.  This has had an enormously positive impact for the adoption of identity smart cards and related products in the U.S. Government.  PIV was also a huge boost TrustBearer’s industry.  Now, state & local governments and private companies are starting to take advantage of this federal government investment.  See the CIO Council’s PIV-Interoperable document.

The scope of the PIV specification was deliberately limited to address the requests in HSPD-12.  PIV defined a smart card application for usage, but not for card personalization.  PIV also defined a very specific card data model intended to store information that would be helpful to identify federal employees and contractors.  Organizations outside the federal government are now trying to adopt PIV, but are finding that these deliberate limitations make PIV a less flexible identity standard.  Consider healthcare: PIV does not define nor provide a way to extend the data model to record clinical information like allergies or medications on the card.

A More Flexible Identity Credential Standard

As Mike Neumann mentions in his presentation from earlier this year,

ISO/IEC 24727 is a framework for interoperable IAS [Identification, Authentication, Signature] systems.

It provides abstraction at every level of an IAS system, including the card data model & associated security model, card administration, communication protocols, and authentication protocols.  Even the testing section was developed to be completely extensible.  When these concepts and this image were first presented, I was a bit overwhelmed.

This was such a leap beyond what PIV and CAC tried to accomplish that I really needed those few days to digest the breadth of the 24727 standard.  I like to think about it this way – 24727 gives

  • Card operating system / applet providers, and
  • Card Management System (CMS) providers

a standard way to describe the card/applet’s

  • technical capabilities (e.g. crypto)
  • data model
  • data security model
  • administrative capabilities (for personalization / lifecycle management)
  • communication protocol capabilities (e.g. APDU, TLS)

for use by

  • Card middleware providers (e.g. TrustBearer), and ultimately
  • Client applications (e.g. Windows, Custom smart card viewer, Web services)

Before this standard, there were always some functionality limitations in layers between these components.  By functionality limitations I mean that layer x (e.g. application) could not access (or didn’t know how to access) a feature in layer y (e.g. specific data container on card).  To pick on one at a relatively high level, consider PKCS#11, commonly used in non-Microsoft browsers and Email clients.  PKCS#11 allows client applications to use digital certificates and keys stored in a variety of locations – usually in software or hardware (smart cards).  Smart card middleware vendors provide PKCS#11 modules to communicate with the smart cards that they support.  PKCS#11 allows for a single PIN or passphrase to be entered, typically to gain access to use a private key located on a smart card.  But what if different PINs are used for different keys or different operations on those keys (e.g. signing v. authentication)?  PKCS#11 doesn’t support it.

To borrow another description from Mike’s presentation, he describes two approaches to previous standards / specs:

“client-down”, e.g.

  • PKCS#11 – general, but uncoordinated across API
  • CSP – Single function of a single application view

“card-up”, e.g.

  • All of ISO/IEC 7816 series
  • (Nearly?) all middleware based on ISO/IEC 7816

ISO/IEC 24727 is the first series of standards to be designed with both in mind.

This is a helpful way to start to get a feeling for the scope of 24727.

6 Parts

24727 is divided into six parts (and ISO & IEC will be happy to take your money to download each one).

  • Part 1: Architecture – The diagram you saw above, plus some more detail;  The shortest of all parts
  • Part 2: Generic Card Interface (GCI) – Provides a well-defined syntax to describe any card’s data model, security model (Access Control Lists), and capabilities;  Allows middleware to talk to a card without knowing the specific card edge commands
  • Part 3: Application Programming Interface (API) – Provides a well-defined syntax for client applications to communicate with the GCI;  Apps can discover data on cards they’ve never seen previously
  • Part 4: API Administration – Used for secure communication to the card and lifecycle management;  This was added as  a new work item while developing the spec;  It addresses end-to-end security, connectivity, secure messaging, stack configuration & use, and interface devices (IFD)
  • Part 5: Testing – Baked in from the beginning, there’s a model and test script to help prove compliance with the parts that your product claims to implement
  • Part 6: Register Authentication Protocols (AP) – A maintained list of commonly used authentication protocols, such as internal authenticate and external authenticate;  Industries will need their own domain-specific APs, and this allows them to register specific APs to share with others. (See PIV for PACS or MR-PIV and PLAID for examples of a newly proposed APs that could be brought into this part of 24727 someday)

I am just scratching the surface here.  Each of these parts could be another post on its own.  There are some really interesting concepts introduced in the details.  Such as the Part 2 translation scripts – this is where the conversion from a card protocol, like APDUs and the Part 3 API is made.  In some cases, a card could actually store ISO 20060 bytecode that describes its data model and supported functions.  Middleware could then download and run this bytecode to make these translations in real-time.  This is, of course, for new cards that adopt the standard at the card level.

Transition from Existing Applications and Cards

While it would be great if every opportunity out there was a greenfield, like the Queensland Driver’s License project, there are many well-established identity programs with cards already in use, such as CAC and PIV.  24727 can be adopted at various parts.  NIST gave a demo at the workshop of a 24727 Reference Implementation for PIV smart cards.  Ketan Mehta and Hung Dang implemented parts 2 and 3 and hooked this up to a Cryptographic Service Provider (CSP) on Windows to demonstrate smart card logon.  They also connected a PKCS#11 module on both Windows and Linux to their 24727 ref imp to demonstrate email signing on both operating systems and smart card logon using PAM on Linux.  All of this was accomplished without modifying the actual PIV card at all.

During the wrap-up on the last day, Bill MacGregor said this ability to work with existing, deployed tokens was one of his two top benefits of 24727.  The other was the identity abstraction layer in part 3, which provides a tool to think about digital identities and tokens that we have not had in the past.  There are no promises that the next revision of FIPS 201 / PIV will utilize 24727, but I believe it is being considered as a possibility to extend the current PIV standard while remaining backwards compatible with existing PIV & CAC cards.

Generic Identity Command Set (GICS)

We had a Q&A session on the last day of the workshop, and I asked about GICS, which is yet another smart card technical specification that primarily came from industry (INCITS B10.12).  This presentation from Oberthur at CTST this year gives a helpful background and details about the in-progress spec.  The motivations behind developing GICS are interesting.  The presentation starts out by listing all the government endorsed standards released over the years: GSC-IS 2.0, 2.1, PIV’s SP 800-73, 800-73-1, then 24727.  Then it follows with the statement that this costs industry a lot of money to make products that comply with these changing standards, but there’s not much ROI from deploying these changes in the market.

Summer 2006: Using experiences from the development of PIV products, a group of smart card technical experts from the industry decided to work together to define a stable generic card command set that would piggyback on the PIV End Point card edge developed by NIST, but extend its reach outside of the Government area, to extend the market.

GICS is a proposal from the smart card industry to preserve the existing investments of PIV, TWIC, etc. and address the needs for greater interoperability for new card applications other than PIV (or maybe those that have derived from PIV).  GICS introduces a standard card command set, not a new card application command set.

You can see the full list of expected benefits in the presentation, but essentially GICS is trying to standardize an extensible smart card command set for identity cards so that when a card or applet vendor makes an investment to develop products that comply with this command set, the market for these products is much larger than it would be for a specific command set (e.g. PIV).  Certification (like FIPS 140) could be performed on a single GICS card / applet one time rather than an a card/applet for each different identity specification.

The technical characteristics in GICS cover a wide range of capabilities found in modern smart cards: Data objects, parser, templates, tag lists, and even On-Card fingerprint verification.  It also includes a set of common Authentication Protocols and allows that list to be extended.

Sounds a lot like 24727, right?

While it does have some similar goals in extensibility and interoperability, GICS does not go nearly as far as 24727.  It sticks to smart cards and APDUs.  It builds atop PIV to allow for PIV Interoperable and PIV compatible specs to be invented and implemented without requiring yet another applet that needs to be certified.  It stays within the smart card middleware world that we know today.  At the conference Mike Neumann said that 24727 and GICS work together.  From his presentation that I referenced earlier, “ISO/IEC 24727 defines the system interfaces; GICS defines the card commands.”


My goal in attending the workshop last week was to learn about ISO/IEC 24727 and understand how it affects TrustBearer’s business.  Among other things, we provide middleware software that allows all kinds of applications and devices take advantage of high assurance identity credentials like smart cards.  Technical identity standards like PIV and ISO 24727 often indicate that there will be a market for the types of products that we build.

24727 is the first attempt I’ve seen at taking a brand-new look at how identity credentials and systems could be made much more interoperable.  This is an extremely extensible specification.  Data and security models can be discovered.  The communication protocols can evolve – imagine not needing to know what an APDU even is! From a technical perspective, these concepts and the proposed architecture are very impressive.  But the level of abstractions introduced in this specification couldn’t help but remind me of Spolsky’s posts on architecture astronauts.

Does 24727 have too much abstraction?  Is there really a market demand for the concepts introduced in this standard?  That is the top question in my mind.  It was helpful to hear from Alex Gagel, one of the lead architects on the Australian Queensland Smart Driver’s License project.  That smart card project is clearly the largest and most thorough implementation of 24727 to date.  Alex and his team are such early adopters of the standard that they are the editors for parts 5 (Testing) and 6 (AP Register) of the standard.  This FAQ states that the European Union Citizens Card, German Smart ID Card and German Electronic Health Card will also be adopting 24727, but to what degree I am not sure.

Is GICS a more practical step in the right direction?  I can say that from a middleware and card application provider perspective, GICS has a more well-defined scope and short-term value proposition for the U.S. ID credential market.  GICS has the luxury of building on top of an existing standard (PIV) and it’s scope us much more narrow than 24727.  Is GICS itself sufficient for the next 5 years?

<ISO/IEC $$$ rant> I do not have all the information on why ISO and IEC charge money to download their specifications, but coming from the technology / Web 2.0 industry, where companies are dying to give away their API documentation in order to drive adoption… I don’t get it.  How does charging anywhere from $95 USD to $245 USD for each part of the 24727 specification encourage the world to adopt this interoperability specification?  It just doesn’t make any sense to me. </rant>

**COUPON: On that topic, we were informed at the workshop that ANSI has an agreement with ISO/IEC to sell each part of the 24727 spec for $30 USD.  Access the ANSI eStandards Store and search for 24727 to see each part – the discounted ones are at the bottom.

TrustBearer will be keeping an eye on the adoption of 24727.  Until we see a significant demand coming from our existing customers and focus markets, we will probably not begin to adopt these concepts in our software.  That said, I would like to hear the opinions of others who stumbled across this article.  Is 24727 affecting development of your products today?  And for those in charge of identity programs, will 24727 be a cornerstone of your next ID credential?  Please email me or leave a comment.

Presentation References

NIST said that all the presentations from the workshop should be eventually published online.  For now, I’ll embed the two that I found very helpful when writing this article.

Mike Neumann’s 24727 & GICS Presentation

Oberthur’s GICS Presentation