TRI-D Software Architecture

Introduction

TRI-D Systems manufactures ISO 7816 compliant flexible display cards. Cards are available in various configurations, with any or all of printability (badging), smart card, proximity access, enroll-on-card match-on-card biometric authentication, and One-Time Password features.

The One-Time Password (OTP) function is the only one that requires custom (TRI-D specific) software support in the IT infrastructure. This document describes the components that make up that software.

The reader should be familiar with the basics of authentication and system design. It is also helpful to be familiar with unix terminology.

Background

Today's authentication servers range from barely adequate to highly available multi-master designs. But even the best of them is not designed to work with OTP because they don't have the ability to update authentication state everywhere before an authentication finishes. This is required for OTP in order to avoid replay attacks. If a user can authenticate to one server with a given passcode, that passcode must not be subsequently usable on another server.

With only a single authentication server, passcode reuse cannot occur because that single server knows every passcode that was used. But today's systems are widely distributed for reliability and availability, not to mention for sheer capacity reasons. With even two servers, it becomes vastly more complex to guarantee OTP semantics when failure modes are taken into account.

It is clear why general purpose authentication servers aren't designed for this—static passwords do not suffer from replay attack races. The password you use at one time on one server is the exact same password you will use at another time on another server. If you also consider that multifactor authentication is relatively rare, it is the correct design choice (needs-driven) to trade-off real-time consistency for simplicity, availability and speed. General purpose servers do need to replicate state in order to enforce lockout rules, however, only loose consistency is required.

Overview

The basic TRI-D architecture is to add a small plugin to existing authentication servers (krb5, LDAP, RADIUS, PAM, etc.). That plugin has the simple task of communicating to otpd, the TRI-D One-Time Password daemon. Even when taking the inadequacies of general purpose authentication servers wrt OTP into account, this is still a significant advantage over other (competitors') designs, as the complex job of a general purpose authentication server does not have to be handled.

otpd performs all One-Time Password verification functions as well as local state management (state consists of data like last used passcode, time of last authentication attempt, number of consecutive failures, etc.).

The built-in local state management of otpd is adequate for small deployments because the typical small configuration is only two authentication servers in a primary/backup configuration. An out of band method to replicate state from the primary to the backup server generally suffices.

But in order to scale beyond that and to allow for load balancing (as opposed to primary/backup failover) across authentication servers, distributed state management needs to be added. This function is performed by gsmd, the TRI-D global state management daemon.

We now present the classic block diagram:

The large dashed box represents a single server. Within each server, the larger solid boxes represent processes; the relative size of those boxes is a rough attempt to indicate relative complexity (to be more accurate, the authentication server box vary in size depending on the server). The smaller interior boxes represent plugin functionality. Solid arrows show external (interprocess) connections and hollow arrows show modular functions supported by plugins. Plugins shown are not necessarily the only ones supported, specifically, otpd can authenticate other card types not shown, and users are free to add their own proprietary functionality.

As seen in the diagram, otpd can either obtain state from local files, or, if a distributed configuration is desired, it can talk to gsmd.

gsmd is shown running on a separate server, but that is just to demonstrate its capability to do so. It is more likely that most installations will prefer to run it on the same server as the other components. Also, while only a single gsmd is shown, there can actually be any number of them.

Component Operation

otpd

Upon receiving an authentication request via the server plugin, otpd consults a user database, currently either a local file (/etc/otppasswd) or an LDAP directory, through a userops module. Other userops modules could easily be written, say to support NIS or a SQL database; but LDAP, which includes Windows Active Directory, should meet most needs.

After verifying that the user exists, a state request is made, either locally or remotely as required by configuration. If state already exists for the user, lockout rules are applied. Even if the user is locked out, the OTP verification step is performed for logging reasons.

If state does not exist, then an initial state is created if the module for the card/token held by the user supports it. This eases user provisioning and disaster recovery, reducing the cost of system administration.

OTP verification is done by asking the cardops module (specific to the type of card the user holds) for a sequence of OTPs in a range given either by manual configuration, or if the card supports it, auto configuration.

otpd then decodes the authentication request and determines if an OTP in the range matches the user's PIN+passcode entry. The otpd core does the verification, rather than pass the user's passcode entry to the cardops module for verification because some types of authentication requests have complicated pre- and post-processing requirements; it does not make sense to have the cardops modules each have to independently implement these functions.

Before returning status to the authentication server plugin, otpd updates the user's state. This step and its order is extremely important; if state cannot be updated, then replay or guessing attacks become possible.

gsmd

Although multiple gsmds can exist, each one holds state for a subset of users with no sharing. This is to allow maximal scaling of gsmd. If state for a given user were shared among multiple gsmds, there would have to be a global locking protocol with quorum locks required. This would create an n² communications problem, and complicated network partition problems and global state resynchronization would have to be addressed. Additionally, for geographically distributed infrastructures, state requests would become highly sensitive to network latency and reliability issues.

However, this more simplistic no-sharing model creates an availability problem. To address that, gsmd is implemented as a primary/backup system. It would be unacceptable to have even a subset of users be locked out because of a gsmd failure or just normal operating system maintenance.

SURASM

In order to properly evaluate an authentication system, not only must design factors (Security, Usability) be considered, but operational factors (Reliability, Availability, Scalability, Manageability) must also be taken into account.

Security

The most important point to be made here is that all TRI-D infrastructure software is either open source, or source-available. This is not just a marketing tactic; this should be a critical factor in any evaluation of authentication software.

Identity is the basis of the security infrastructure. If identity is not assured, other controls have limited value at best. The software that provides trust assurance to the rest of the infrastructure should not itself have to be blindly trusted.

While source code availability does not assure security, it does assure verifiability. Organizations can independently verify the integrity of the system, and TRI-D can take advantage of third-party evaluations and improvements.

A secondary point is that otpd's modularity allows for custom OTP algorithms or third-party cards to be supported. Users are thus not limited to algorithm "choices" forced upon them by a vendor, which in most cases are not revealed, even under NDA.

TRI-D's cards mirror the openness of otpd and have two standard algorithm choices, RFC 4226 HOTP and a TRI-D variant called IOTP (Improved HOTP). TRI-D's cards also support fully custom algorithms which the user can deploy as a fully site-local feature, i.e. TRI-D need not be involved or even aware that a custom algorithm is being used.

Usability

As this is server-side software, there are not many usability concerns. All software runs as a standard daemon (unix) or service (Windows). Configuration files are flexible and simple to understand.

Since standard authentication protocols are used, client-side software issues are nonexistent.

On the hardware side, TRI-D cards speak for themselves. As a time-based system, there are no issues with card vs. server sync problems that are found with event-based systems. TRI-D cards have reasonably good clock precision and are not susceptible to battery life/capacity induced drift, and on the server side our software intelligently compensates for constant or even varying drift.

TRI-D cards are also available with mixed time+event sync mode, which has all the benefits of a time-based system, including inability to pre-generate passcodes, and the event-based capability to log in to multiple systems faster than once per minute.

Reliability

Reliability is the assurance that any given system component is working correctly. It can be affected by hardware faults or software bugs.

Taken on its own, the TRI-D software is fairly simple, which is actually a design criteria. Simple = Reliable. There is some complexity in gsmd due to the requirement for high concurrency, but standard design patterns are used.

As part of the authentication system as a whole, the TRI-D software is dwarfed in complexity by the authentication server itself. Since TRI-D just piggybacks onto the existing authentication server, adding the OTP components shouldn't negatively affect the reliability of the system.

Availability

Availability is the extent to which the authentication service is responsive to user or client system requests. No system can be 100% reliable—an infallible computer cannot be built at any price and, even if it could, it would still be susceptible to physical disasters. Thus, the vast set of protocols created to deliver high availability.

TRI-D's architecture incorporates high availability by design; there is no need to use external techniques, which are typically complex, to achieve availability goals.

Scalability

Scalability is a measure of efficiency in increasing the capacity of the authentication service.

This is an area where the TRI-D architecture really shines. All of the heavy lifting can be pushed to the edge where the system can scale linearly and arbitrarily. The benefit of having a separate gsmd is that this necessarily centralized function is as lightweight as possible. A single gsmd is lightweight enough and handles so little data that on modern hardware with solid state disk it can scale to any size deployment. However, with very large deployments it is likely that the userbase and authentication servers are geographically distributed. In that case, it makes more sense to also distribute gsmds to be near the authentication servers where each one handles less load. In that configuration, previous generation (read: inexpensive) hardware is sufficient.

It is unlikely that a production environment exists that TRI-D software cannot support.

Manageability

Reliability, Availability and Scalability are always given headline attention, but Manageability is just as important. Many extremely high RAS systems exist which still fail due the the complexity of managing the system.

The TRI-D software is easy to install and configure, and requires no ongoing attention. It simply runs. gsmd failover and recovery is automatic. When using TRI-D cards, even disaster recovery needs no special procedures (TRI-D cards support self-recovery if state data is lost).

User (card) provisioning and de-provisioning is also easy to fit into existing processes. Auditability is improved thanks to the use of LDAP—standard tools can be used to query the directory.

Summary

TRI-D's novel software design offers multifactor authentication that works in all production environments with minimal integration concerns, can scale to any size deployment and is easy to install, configure and audit. The open source and open standards philosophy offers verifiability that is not available from any other vendor. TRI-D's software can easily support other vendor's products, and in some cases already does. Don't get locked into another vendor's closed, proprietary, expensive and unverifiable (and thus untrustworthy) solution.

The software design complements TRI-D's hardware perfectly. TRI-D cards are highly secure, highly integrated and highly configurable, yet simple to use. They are the most convenient form factor available, and have the highest levels of user acceptance, a critical but often ignored factor. Because source code is available, the hardware is decoupled from the software; customers are free to write their own software if they choose.

Please contact sales@tri-dsystems.com for more information on any aspect of TRI-D hardware or software.