Category Archives: product

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

Internationalization in TrustBearer Products

Introduction

Here at TrustBearer, we’re working on reworking the underlying pieces of our software to provide services which are required for full treatment of internationalization issues from cultural sensitivity to language translation.  Fitting such an infrastructure onto a vast existing system of hardcoded, interlinked modules which span multiple (programming) languages and techniques on several platforms is a challenge, but we have come a long way to eventually realizing the goal of true international support.

Issues of Internationalization

The most obvious issue of internationalization is the language in which the user interface is presented; if your audience only speaks French, or perhaps just as importantly prefers to speak French, then you need to offer a user interface in French.  Secondary issues can carry much more subconscious weight, however: as individual cultures have risen and separated from one-another across the planet, even in the age of international commerce and communication that the Internet conveys, specific communities still carry important symbols, ideas, and values which are intrinsically and uniquely their own.

The meaning of colors varies from one society to another, as does the importance of iconography.  For example, the dagger (†) bears similarity to the Christian cross (which it should, since that was part of the original meaning conveyed in its use) and should be used carefully, even in purely typographical meaning, to avoid unintentional religious connotations. This sort of care is often given nary a second thought by those responsible for internationalization strategy, and it’s important to address it just as evenly as one addresses language.  On the subject of translation, there are many things which carry over along with the baggage of verbal communication: formality, dialect, the hints and subtleties that individual words carry both inside and outside of specific contexts, all of these come into play with deciding on a technique for providing the infrastructure with which to provide international support for a software system.

Implementations

There are four fundamental systems in TrustBearer’s overall product ecosystem: the web plugin with dynamic device support, the browser, static web content, and the server.  We have chosen to implement three components which satisfy the translation needs of all four pieces.

Plugin, Device Support, and JavaScript

We implement dynamic translation features in the plugin as a module, which is loaded at run-time just like device support is.  In this way we offer the ability to switch languages in real-time.  It also gives us the luxury to download translations from a server where they can be modified on the fly without the need for any kind of recompilation or redistribution.  Because our plugin and the methods of its modules, which have been marked with the appropriate access level, are accessible from JavaScript running in the browser, we can extend such dynamic translation support to the browser as well.

Translations are conducted using a very simple macro language inspired syntactically by TeX.  It allows placement of separately translated arguments in arbitrary order (to facilitate support of languages such as German which have different or flexible word order structures) and automatic construction of quotation marks (to handle nested quotations build from separate translations substituted as in the previous remark).  Because of the nature of the system, new extensions can be added but this will not complicate the writing of a translation module: the goal is to allow our customers to be able to modify these to substitute their own language if they see fit.

Static Web Content

The exact same translation module drives a compile-time tool to create static versions of web pages, style sheets, and so forth which support individual cultures.  This step occurs automatically using pkgBuilder, the tool used throughout TrustBearer for building all systems we produce.  The result is a collection of HTML files, one for each culture which is supported.  Customers are then free to select from the available languages to deploy, and to use their webserver’s rewriting capabilities to send e.g. their Norwegian users to index.no.html rather than index.en.html.  This provides a balance between computation time required and flexibility offered; while TrustBearer’s clients no longer have the capability to retranslate pages without any extra work, their servers will not be constantly working to provide the latest translated version when such is very unlikely to change with any notable frequency.

Daemon

The core TrustBearer server, which we simply call “the daemon,” rarely provides information directly to the user.  Rather, it contains a lookup system to check incoming error attributes against a database and return a corresponding message which is meaningful to the humans who will diagnose or work around problems.  For quite some time, the daemon has used the client’s language (as provided by their browser) as a means of looking up these human-readable messages.  Little to no extension of this system is necessary to continue to provide error and status messages to users in the languages in which they are accustomed to communicating.

The Road Ahead

While the architecture of the internationalization system is fairly set, the work on retrofitting this into the existing system is just beginning.  Over the next few months, we will be externalizing strings and incorporating the new methods of translating messages dynamically.  TrustBearer’s head engineer, Eirik Herskedal, is from Norway and will be providing a pilot translation into his native tongue for us to begin testing with.  The testing and quality assurance process will take the longest, but features in the translation system (for example, XXX’ing out strings for which no translation exists) will make this process smoother.  After several months, we expect these features to enter beta use by our most prestigious customers. Then, with the consideration of customer feedback,  these features will be added to all of our future deployments.

Software systems that work with the cultural complexities and sensitivities of their users, rather than against them, are woefully under supplied.  At TrustBearer, we value the differences in our users, and wish to better cater to the multi-faceted nature of their individual societies.  By starting this long work to implement internationalization features in TrustBearer products, we begin down the road of providing our system in a way that works best for you, whoever and wherever you may be.

Calling all device providers: Get your own OpenID & SAML Provider

Just over a year ago we launched the first* OpenID Provider that exclusively supported smart cards and other USB security devices. Last summer we added SAML login support for Google Apps & Salesforce.com. One of the groups of people that has been most interested in our OpenID provider has been device manufacturers: the companies that make and resell smart cards, biometric readers, and various other types of USB security devices.

TrustBearer OpenID gives these device providers a simple way to demonstrate the value of their devices to end users. It lets users login to useful online services with a very secure cryptographic hardware device. The one question that these customers might have is: Who is TrustBearer?

We are answering that question today by making it irrelevant! TrustBearer is now offering a service to create and host custom-branded OpenID & SAML Identity Provider to security device providers and resellers. This service includes,

  • A custom URL (such as https://superCard.mySmartID.com)
  • Custom graphics and theme for the site
  • Custom application settings & links for OpenID & SAML sites that are relevant to their customers

We are charging a one-time set-up fee and a monthly fee to create and host this service. Please contact us if you are interested.

Custom OpenID / SAML Identity Provider

* I believe we were the first to launch an OpenID Provider that exclusively supported smart cards. C’mon, it made Slashdot.

TrustBearer Device Personalization

We recently made some updates to a tool that we’ve been using internally for awhile called TrustBearer Device Personalization. This site lets you initialize many of the devices that we support in our applications, such as TrustBearer OpenID.

Device Personalization Overview

For those of you familiar with the personalization capabilities of smart card management systems, this tool provides very similar capabilities: On-card private key generation, digital certificate loading, and data object loading. The web service is connected to our (self-signed) Certificate Authority and generates certificates using the request signed by the private keys on a user’s device. The tool lets users specify the key size of the public key in each certificate (currently 1024 or 2048 bit RSA keys).

We also support personalization of several data objects on PIV-compatible smart cards and devices. See Part 1 of NIST SP 800-73-2 for details on these data objects. This is helpful for users developing applications that read these PIV data objects. Several card manufacturers and software providers have been using this feature for a few months.

PIV Compliance

Once a device is personalized, you can use the TrustBearer Device Viewer to view the certificates and data objects that were loaded onto the device. If Load Sample Data is selected, you’ll notice that a JPEG 2000 image is loaded onto the card. In the future, we may add the ability for a user to upload an image.

TrustBearer Device Viewer

Now, for those of you who think this is a great tool to clear your friend’s official card… We’re sorry! This site will only work with with smart cards and devices that contain “developer” administrative keys. Any official smart card worth its weight will require a unique administrative key to perform updates. TrustBearer Device Personalization has administrative keys built-in for a number of sample PIV cards (such as Oberthur and Gemalto). If you have a sample card to which you know the administrative key, the site will prompt you for the administrative key while it is performing a personalization. If you have a TrustBearer Key, your user PIN is your administrative key.

Be careful if you personalize a device linked to an account, such as TrustBearer OpenID. Personalization will erase the existing keys and certificates that you select. If you don’t have a backup device linked to your account you will no longer be able to access your account.

TrustBearer Personalization Warning

With that said, we hope that you find this tool useful. Post a comment or send us an email if you have any questions.