Sean Convery

Since my last two posts have been about biometrics how about one related concerning crowd facial recognition? Bruce Schneier points to German test results (in German):

Two hundred frequent travellers volunteered to have their faces recorded and three different systems tried to recognize the faces in the crowds of a train station. Results (in German): 60% recognition at best, 30% on average (depending on light and other factors).

Facial recognition in a crowded public place seems like an extraordinarily hard computing problem to solve. Oditogre, an early commenter to Bruce’s original post raises an interesting question:

Google translator mangled it pretty badly, but I got the gist enough that it didn’t seem to say how many false positives there were. That would be the biggest issue, to me. If they can achieve 30% recognition rate with 0% false positive rate, that could well be a very effective system for catching fugitives, but otherwise, it’s just going to be a bad waste of money.

I personally don’t see how you can have a 30% success rate with zero false positives. Network IDS systems can’t prevent false positives and they’re working with binary data. Later on in the comments it appears that the false positive rate was .1%. While this may seem good, imagine how many folks will walk past a particular point in Times Square today or the Otemachi metro station in Tokyo.

Technorati Tags: biometrics

Dr. Terry Boult, of the University of Colorado Vision and Security Technology Lab, responded to my last post with some excellent research that is much more current than the paper I originally mentioned. I haven’t had time to drill into all of it but the first paper from Arun Ross, Jidnya Shah, and Anil Jain entitled From Template to Image: Reconstructing Fingerprints from Minutiae Points was very interesting. Based on my cursory examination, it seems to confirm the 2003 paper’s hypothesis that reconstructing biometric data is possible for other types of biometric systems beyond those employing facial recognition:

The salient feature of this noniterative method to generate ridges is its ability to preserve the minutiae at specified locations in the reconstructed ridge map. Experiments using a commercial fingerprint matcher suggest that the reconstructed ridge structure bears close resemblance to the parent fingerprint.

He also points to some research on “cancelable biometrics” including a paper of his own (link is dead for some reason). The IBM Exploratory Computer Vision Group has a brief description of how one system works. The full paper can be found here. In short, the system seems to distort the original biometric in a repeatable way so that each time the biometric is entered it is only stored in its distorted form, never in its original form. If it gets compromised you can issue a new biometric “distorted” in a different way. I haven’t looked through the other papers yet but if they work similar to the IBM proposal I have some questions.

I’m not sure exactly how this is different from the “template” of a normal biometric except perhaps that the user could control the process? Assuming it is different, the problem I see is how do you know whether the biometric system you are using supports this capability? Say your OS supported this function but your bank or government didn’t. If you are using fingerprints for all of them we’re back to the same problem that Dr. Boult calls the “biometric dilemma.” Also, doesn’t the biometric scanner need to keep your biometric data originally (even if only briefly) in order to distort it? If so, we’re back to my “perfect system” assumption.

It still seems to me that the way to truly revoke a biometric has more to do with medicine and surgery than it does with information technology. I look forward to getting better educated on this in the future and I’m glad to see research underway.

Technorati Tags: biometrics

To the surprise of–I’m hoping–fewer and fewer people, Andy Adler at the University of Ottawa has published a paper showing how the digital template of biometric data can be reformed into a close approximation of the original biometric data. The example uses facial recognition but according to the paper, “While results are demonstrated for face recognition algorithms, the conceptual framework should be applicable to any biometric algorithm.”

Kim Cameron’s blog pointed me to this, though the paper’s header seems to indicate it was published in 2003. Late last year I revisited my thinking on Biometrics here; it all still applies. Any security system will have vulnerabilities of some sort or another. One of the considerations though, is what the impact is of any single vulnerability. With biometric systems, because the same biometric data can be used in multiple places, the impact could well extend beyond the exposed system. This makes the security of your biometric data only as strong as the weakest place that stores it. When that reality is coupled with the truism that you can’t revoke your biometric data, we wind up with a real problem.

Technorati Tags: biometrics

Part two of a two-part article titled Network Authentication, Authorization, and Accounting was just published in the Internet Protocol Journal. I wrote the article to be a survey of the entire AAA space and so it covers a lot of ground without spending too much time in one place. If you are new to AAA or are looking for a conceptual model of AAA to help others grasp its concepts, please take a look. Here’s a snippet:

Network Authentication, Authorization, and Accounting has been used since before the days of the Internet as we know it today. Authentication asks the question, “Who or what are you?” Authorization asks, “What are you allowed to do?” And finally, accounting wants to know, “What did you do?” These fundamental security building blocks are being used in expanded ways today. The first part of this two-part series focused on the overall concepts of AAA, the elements involved in AAA communications, and high-level approaches to achieving specific AAA goals. It was published in IPJ Volume 10, No. 1. This second part of the series discusses the protocols involved, specific applications of AAA, and considerations for the future of AAA.

Although AAA is often thought of as the exclusive province of the Remote Authentication Dial-In User Service (RADIUS) protocol, in reality a range of protocols is involved at various stages of the AAA conversation. This section introduces these AAA protocols, organized according to the parties involved in the communication. We divide AAA communications into the following categories: Client to Policy Enforcement Point (PEP), PEP to Policy Decision Point (PDP), Client to PDP, and PDP to Policy Information Point (PIP).

You can get the HTML or the PDF.

Technorati Tags: 802.1X, AAA, IPJ

My fellow OpenSEA colleagues Messers Oltsik and Gast have both recently pointed to the need for more 802.1X support in non-PC devices. Last year I made a post indicating that support seemed to be improving and I certainly agree that OpenSEA can help accelerate this. The iPhone is definitely a step in the other direction though. As Matthew points out, Mac OS X already has a native supplicant and the iPhone supposedly runs Mac OS X. I’m guessing this is more a matter of QA resources butting up against launch plans than anything else; my iPhone’s browser still crashes from time to time which certainly seems like a higher priority.

I wonder how sensitive the multi-touch interface is? It would be interesting if you could record guestures as a way to access a password wallet. The iPhone keyboard does a great job of correcting common English language mistakes but it is quite horrible at entering passwords like dkIH$l_73n!.

On an unrelated note, seeing that Matthew is using the same Wordpress default template as I am left me feeling sheepish. As Jack says about Marla in Fight Club, “Her lie reflected my lie.” Oh well, none of you really suspected I had any HTML skills I’m sure.

Technorati Tags: 802.1X, Supplicant

With the news that inline NAC vendor Caymas Systems has gone under, questions from the customer base are bound to come up about the merits of buying products from startups. Time Greene over at Network World has been following the story and has a quote from just such a concerned customer. Kim Hansen at the City of Sioux Falls said:

I can guarantee you that our next SSL vendor will be based on size and dollars, and not just features and ease of use. I need a company that is going to be around in the long run.

Working at a startup myself it is easy to be alarmed by Hansen’s comment. I even sat on a panel at DIDW with Sanjay Uppal, Caymas’ former CEO. There are a few lessons here for vendors and customers alike looking at the startup space.

1. Demand standards - I can’t tell you how many times I’ve used IDE’s support of standards to mitigate concerns with deploying technology from our relatively young company. While this certainly can’t completely save you if a startup fails, it does improve the odds that you can salvage some of the work you’ve done if you ever need to find a replacement. Real customer loyalty comes from executing on standards better than anyone else, not from locking folks in to proprietary solutions.
2. Be extra diligent with data-plane solutions - Caymas’ product sits inline to the flow of network traffic. By offering advanced firewall capabilities and hardware-accelerated traffic inspection, products like Caymas add new functionality over and above what most customers have in their existing infrastructure. However, this technology often comes at a steep cost in up front dollars and ongoing support and administration. I’ve gotten feedback from a number of customers who are wary of new inline solutions. Part of it is Hansen’s newfound concern, but another part is just the comfort level of putting a brand new vendor, regardless of their reliability, inline within an existing functioning network. The “if it ain’t broke…” adage seems to apply here. Control-plane solutions that leverage functionality on existing infrastructure gives you a natural escape valve; you can always turn the new feature off and be right back where you were.
3. It isn’t about the awards - Caymas, whose website was still up at the time of this writing, has a whole bunch of awards from the likes of Forrester, Gartner, and Infoworld. These types of awards are designed to encourage a customer to buy a product, and make them more comfortable with that decision. A better metric for the skeptical IT buyer is customer count and growth path. How many customers have bought the product and deployed it in production? What is the growth tragectory in the customer count since the company first shipped product?

Walking away from startups completely will limit any company’s ability to solve leading-edge problems quickly. While sticking only with established vendors is a choice some companies make, you sacrifice a lot by doing so: not only do you lose the technology advantages of the startup, but also the enhanced responsiveness of a startup to your organization’s specific needs. Startups can play a role in most organization’s networks, they just need a bit more attention to the purchase decision than selecting the offering from your favorite giant vendor.

Technorati Tags: NAC, security

The IETF draft I’ve been tracking that defines a common format to communicate IP ACLs via RADIUS is now an official RFC. 4849 has a nice ring to it, hopefully it will become part of the networking and security vernacular like 1918 or 2827. Remember the RFC doesn’t mean anything until the industry builds support into its products. If you are a customer of Cisco, Juniper, Nortel or any other networking vendor I encourage you to ask for RFC 4849 support as soon as possible. Supporting it makes sense in almost all access devices: firewalls, wired switches, WLAN APs, and VPN gateways. Enabling role-based access control throughout your network is becoming less of a dream each day; RFC 4849 gets us one big step closer by defining a mechanism to support ACLs in heterogeneous network infrastructure. Here’s the abstract, scary that I get excited by this stuff:

While RFC 2865 defines the Filter-Id attribute, it requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588.

Technorati Tags: AAA, NAC

With the announcement of OpenSEA and some new announcements from my company, I’ve been away from blogging for a while. Plenty has happened while I was gone. First, Microsoft and the TNC announced that a core NAP protocol would be part of the TNC. Second, OpenSEA got great press and we’re seeing lots of interest from new companies in joining. Finally, Caymas Systems went under making at least one of my blog predictions for 2007 correct. Each of these probably warrants its own post and I hope to get to each soon.

Technorati Tags: 802.1X, NAC, OpenSEA

Today I am thrilled that the formation of the OpenSEA Alliance has gone public. We’ve already had some nice press coverage. OpenSEA (Open Secure Edge Access) formed to promote the development of an enterprise-grade 802.1X supplicant. We’re basing our work on the existing XSupplicant. The founding companies are Extreme Networks, Identity Engines, Infoblox, Symantec Corporation, TippingPoint, Trapeze Networks and UKERNA. Jon Oltsik and I blogged about this a while back and this is the result of Jon’s efforts to corral the right industry players to make this happen. I’ll follow up with another post once I’ve had a chance to digest the industry reaction. For now, the FAQ has lots more information.

Technorati Tags: 802.1X, AAA, NAC, Supplicant

While normally I would shy away from mentioning Identity Engines’ online events here, I’ll make an exception this time. I’m presenting the IdM-N talk on May 10th at 11:00 AM PDT via the web. If you’d like to hear me talk through some of the concepts live and ask questions (though you’ve always got the comments field on this blog) feel free to register. I can’t guarantee one of our friendly sales guys won’t call you, so consider yourself warned. I’ve got a few slides at the end on what Identity Engines does but the bulk of the talk is vendor neutral. The talk will be nearly identical to what I delivered to Secure IT, NYMISSA, and the NAC so if you are familiar with the material in those presentations you can safely skip this one.

Technorati Tags: AAA, Identity Management