This is Steve_Lockstep's Typepad Profile.
Join Typepad and start following Steve_Lockstep's activity
Join Now!
Already a member? Sign In
Steve_Lockstep
Sydney, Australia
Innovator in digital identity & privacy
Interests: Identity Management, PKI, smartcards, privacy, e-health, CNP fraud
Recent Activity
Raghavan quipped "in the days to come, even DNA may be duplicated". Indeed! Pluck someone's hair, or even shake their hand, and you've got enough of their DNA to spoof them. Truly, of all the biometrics, DNA has to be the craziest.
The casual advocacy of biometrics really has to stop. These technologies are not what they seem. Most people get all their understanding of biometrics from science fiction movies, and vendors do bugger-all to round out the public's understanding. There's an amazing double standard where the truism that there is no perfect security gets shoved aside by unquestioned assumptions of biometrics being "unique" (they're just not). But with a few moment's reflection even lay people spot one of the fatal flaws: a biometric cannot be cancelled and reissued in the event it is stolen. With a little more time, business people can get a handle on crucial practical matters like the security-convenience tradeoff, the reality of Reverse Engineering (so much for biometrics being 'impossible to forge' as many vendors claim) and the inherent difficulty of card-less biometric ATMs (which will occasionally commit a False Match and this give you access to someone else's money). So please, you shouldn't even joke about DNA as a biometric. More at http://lockstep.com.au/blog/2012/10/20/biometrics-and-privacy-basics http://lockstep.com.au/blog/2012/05/06/biometrics-must-be-fallible
I have mixed feelings about "Learn to Code" and #codeyear. On the one hand, I hate that for years the "suits" have lectured technologists and scientists to understand business and to adopt business speak. So it's nice now that the onus to understand is reversed a little. It has to be good for managers to have an appreciation of coding. On the other hand, a great deal of the "Software Crisis" can be blamed on programmers themselves not really understanding what they're doing! For a couple of decades, we in software have tended to differentiate "software engineering" and yet we are still a long long way from professionalising what is more craft than engineering. Code is so very unlike the stuff of other professions – soil and gravel, metals and alloys, nuts and bolts, electronics, even human flesh and blood - that the engineering analogy is misleading. By simply coopting the term I fear we have underestimated the fundamental challenge of forging a software profession. It won't be until software engineering develops the normative tools and standards, culture and patience of conventional engineering that the software crisis will turn around. Meanwhile, teaching managers to knock up code could give them entirely the wrong impression. Coding should not be so easy. More at http://lockstep.com.au/blog/software-engineering.html
Toggle Commented May 16, 2012 on Please Don't Learn to Code at Coding Horror
In banking, perhaps the biggest challenge for biometrics is that nobody can say how these things really work until they're put out into the field. The FBI's advice on biometrics is chilling. One of the most comprehensive independent studies of biometrics was conducted by Mitre corporation for the FBI's Biometrics Centre of Excellence. This from one of their technology assessments: "For all biometric technologies, error rates are highly dependent upon the population and application environment. The technologies do not have known error rates outside of a controlled test environment. Therefore, any reference to error rates applies only to the test in question and should not be used to predict performance in a different application." And: "The intentional spoofing or manipulation of biometrics invalidates the 'zero effort imposter' assumption commonly used in performance evaluations. When a dedicated effort is applied toward fooling biometrics systems, the resulting performance can be dramatically different." Ref: Mitre Corporation for the FBI State of the Art Biometrics Excellence Roadmap (SABER) "Technology Assessment: Volume 1 (of 3) Fingerprint, Palm print, Vascular, Standards" 2008; www.biometriccoe.gov/SABER/index.htm That is, most reported biometric accuracy figures are only worked out for accidental errors. Vendors' bench testing deliberately ignores deliberate attempts to spoof the systems. 'Dedicated effort applied to fooling biometrics systems' means criminal attack. If a vendor cannot tell a banker how well a security system actually resists criminal attack, if they have no standardised performance specs to predict how biometrics will go in the real world, then that vendor faces an uphill battle.
Clarifying PKI interoperability I am afraid the way we think about “interoperability” in PKI has been overly influenced by government secrecy classification, and old notions of “key exchange” (PGP) and the related idea of cross certification, which seeks to show that two strangers Alice and Bob have equivalent credentials. Equivalence is irrelevant in healthcare authentication. Counterparties may have totally different roles: one might be an insurance loss adjuster and the other a medical professional submitting a discharge summary in support of a claim, or one might be a government bureaucrat and the other a family physician reporting a case of a notifiable disease. In fact, it’s not always the case that both counterparties to an e-health transaction even have certificates: what can policy mapping and the like even mean then? I submit here a few thoughts on how to think more clearly and elegantly about interoperability. A senior finance sector executive once captured the uncertainty perfectly: “[PKI] interoperability is something of a will-o’-the-wisp. You think you understand what people mean by it, and then quickly realise that you don’t. In my experience, it’s possible when discussing interoperability to be at cross-purposes for all of the time. Interoperability between members of the same PKI is axiomatic. Certificates issued by one bank should be recognisable by another. Interoperability becomes an issue when it is between different PKIs … But this still leaves the basic question of interoperable in respect of what?”. Indeed, interoperability is so very ‘axiomatic’ that many pivotal papers on the topic – like the PKI Forum’s 2001 whitepaper “CA-CA Interoperability” – omit to even define the term, or to spell out its precise objectives. It really isn’t complicated. The best place to start thinking about interoperability is to revisit how digital certificates can help with the act of authentication. From the perspective of the Relying Party, the central question is very simple: What information is available – in the certificate chain and elsewhere – to help decide whether to accept or reject the certificate and hence the clinical document? There are three main things the RP needs to know about a certificate. 1. What representations does the certificate make about its holder? Or equivalently, was the certificate intended to be used in the transaction concerned? Increasingly, digital certificates are used to represent specific credentials or memberships and to thereby confer particular authorisations (see also www.lockstep.com.au/library/pki/relationship_certificates). For example, a certificate issued by a medical authority can confer the rights of the holder to write prescriptions, claim government rebates and so on. Such digital credentials will bear a unique Policy OID, and perhaps the holder’s registration numbers as well. 2. Is the certificate subject still valid (i.e. not revoked)? Sometimes the question will be backdated, because significant time may elapse in healthcare between signing say an EHR entry or a prescription, and that document being relied upon. So the question is, was the certificate holder valid at the time they launched the transaction? 3. Was the certificate issuer acting in compliance with applicable standards and regulations? A CA’s status should be made available online in machine readable form; one way to do this is for a regulator to issue a compliance certificate to the CA in X.509 format, with the regulator acting as a trust anchor for all certificates issued within its domain. All of this information can be incorporated into the certificate chain. A signed e-health transaction should in general be sent along with the entire certificate chain (along the same lines as S-MIME signatures). It is a simple matter for all software apps in a given e-health domain to come equipped with the appropriate trust anchors pre-configured (there won’t be all that many trust anchors, and e-health software is generally ‘high maintenance’, meaning lots of opportunities to install the roots). The outcome then is “application level” interoperability: all the information an application needs in order to accept or reject a certificate can be found in the certificate chain. Yet the now-orthodox way of approaching “interoperability” is through Bridge CAs and elaborate policy mapping. My analysis is that Bridge CAs might not be ideal in decentralised non-government environments. When sender and receiver are in different domains, the fundamental outcome of PKI interoperability should be to deliver those three pieces of information described above to the systems that need it in order to tell if the sender’s certificate is fit for purpose. That is: (1) Does the sender’s Policy OID indicate suitable credentials? (2) Was the sender’s certificate valid at the time of signing? And (3) Was the CA valid at the time? The orthodox approach of policy mapping is an exhaustive comparison of the Certificate Policies (and Certificate Practice Statements) of the CAs of each counter party. The desired end result is a cross-certificate that causes certificates from other domains to chain back to a local root, as if those certificates were equivalent to local ones, imbuing them with the same so-called “trust level”. But cross-certification or policy mapping have several problems. It is laborious. More fundamentally it presupposes that the RP belongs to a PKI, which as mentioned may not be the case. Finally, the fitness for purpose of a certificate (especially in healthcare) is a different sort of property from “trust level”. Digital credentials come in all sorts of shades; it simply doesn’t make sense to compare the generic trust level of say a doctor’s certificate with that of an insurance agent, or bureaucrat, or even another medical professional. How are doctors and nurses “equivalent” for example? It’s a type of category error to construct authentication systems that are preoccupied with equivalence. It is instructive to review why certificate equivalence became so enmeshed in thinking about PKI interoperability. Governments (especially defence agencies) were the first adopters of PKI. In a typical government PKI, trust levels are much like national security clearances. Officials in different domains need to know one another’s clearance levels, in order to judge whether classified information can be disclosed by senders and entrusted to receivers. So the central question historically was: Is your trust level equivalent to mine, or is it higher or lower? The objective of a Bridge CA, in an environment where multiple CAs would otherwise seek cross certification, is to centralise all policy mapping. Instead of all CAs needing to cross-certify in a pair-wise fashion, the aim is that any two given certificates from participating systems can be tested in real time and chained together on the spot if they are deemed equivalent. Yet policy mapping remains very expensive. One senior NIST expert admitted to me in 2008 “Cross-certification and policy mapping has been a rat hole that has sucked up vast amounts of energy better spent elsewhere”. In contrast to classical government PKI, vertical or closed scheme-based PKIs can manage credentials issued for a particular purpose or business application. Trusted administrators vouch for “scheme” members, issuing certificates with a defined scope, which confer rights to carry out prescribed types of transactions governed by the scheme. A “scheme” can mean anything from an employer and their staff, an application with embedded certificates (like Skype), a consortium governing dedicated appliances (like the cable TV set-top box PKI) or an industry with existing business rules and credentialing processes (such as healthcare). Now the Relying Party’s question is much more straightforward: Does your certificate show that you a legitimate member of a scheme I recognise? Unambiguous indication of the scheme to which a certificate belongs – and therefore its fitness for purpose –can be coded by the Policy Object ID, which originates from the scheme administrator, and which can be disseminated via regulators and others. Cross-recognition of these types of certificates is automatic if Relying Party software has knowledge of the expected Policy OID(s), via for example a Certificate Trust List. For further reading, please see: http://lockstep.com.au/library/babysteps/babystep_1_pki_in_health_welf.pdf http://lockstep.com.au/library/babysteps/babystep_12_electronic_medic_.pdf http://lockstep.com.au/blog/2011/01/16/embedded-pki-on-the-cards http://lockstep.com.au/library/pki/known-customer-certificates-a http://lockstep.com.au/library/pki/relationship_certificates I trust that these thoughts are helpful. Stephen Wilson Managing Director Lockstep Group Sydney, Australia E: swilson@lockstep.com.au M: +61 (0)414 488 851 W: http://lockstep.com.au T: @steve_lockstep Lockstep Consulting provides independent specialist advice and analysis on digital identity and privacy. Lockstep Technologies develops unique new smart ID solutions that enhance privacy and prevent identity theft
Steve_Lockstep is now following Erik Pupo
Jun 8, 2011
Dave, I share your frustration - this kind of broken nonsense drives us all nuts. And yet ... the apparent logic of being able to re-use all manner of existing identifiers is not soundly based. So you have a PINSentry, a long-standing billing relationship with a telco, your employer's OTP token, and I gather at least one OpenID as well. But "they all sit in their own silos and don't provide the kind of general-purpose services that they should". With respect, who says they should be so re-used? Your bank, telco and employer don't. What you're asking them to do is make representations about you to a second party (PayPal) with whom they have no contract. Clearly you know this the real problem. You want "potential identity providers (eg, Barclays, O2) to be able to set up OpenID responders for their customers inside a well-known and well-understood legal framework" and you canvass the possibility of IdenTrust-style contracts or new "creative commons licences used for credentials". CC licenses wouldn't ever be enough. Absent new laws to make this kind of grand identity federation happen, we will still need new contracts -- brand new contracts of an unusual form -- struck between all the parties. It's complicated by the fact that banks & telcos don't naturally see themselves as "identity providers", not in the open anyway. To energise them, they need new business models. Worse still, their lawyers will have never dealt with these sorts of multi-party Internet-scale contracts before. It's an intractable task. Silos are inevitable evolved results of the way businesses manage their risks; the way a business knows its customers defines hard risk management boundaries that take years to set up and which cannot be easily modified. Identity silos aren't all bad; they might be rigid but they create transparency and certainty. If Bike Beijing were in the Visa or MasterCard silo, you'd be home and dry by now. Cheers, Steve Wilson, Lockstep.
Gunnar, I agree strongly with you about the importance of coprorate identity policy. Corporate identity has always been critical, even sacrosanct. "Identity" is the way I am know by a business. Identity in each context separates the people a business knows from thos it does not. It has always been thus. So identity is not a "new corporate perimeter"; it is age-old perimeter and very hard to break down in federated identity schemes! See http://lockstep.com.au/blog/2011/02/03/evolved-identity Cheers, Steve Wilson.
Toggle Commented Feb 27, 2011 on The New Corporate Perimeter at 1 Raindrop
Steve_Lockstep is now following The Typepad Team
Feb 27, 2011