[LINK] HIC's Brave New World of Digital Signatures

[Roger Clarke]

Health Minister Wooldridge launched an Internet-based health claims system
on Friday 9 March.  The Media Release will presumably appear sometime soon
at:
http://www.health.gov.au/mediarel/yr2001/mw/wooldr2001.htm

The scheme features key-pairs and certificates intended to enable messages
to be digitally signed.  It is administered by a subsidiary of the Health
Insurance Commission (HIC), Health eSignature Authority Pty Ltd (HeSA).
This gets it out of the Commonwealth.  Possible purposes in doing this may
have included to make it seem like outsourcing, or to escape the public
sector provisions of the Privacy Act.

The following is a first brisk glance at the scheme.  I've been involved in
public key infrastructure issues since the mid-1990s, writing papers,
making presentations, performing consultancies both paid and unpaid, and
submitting to government committees about the serious public policy issues
involved.  See:
http://www.anu.edu.au/people/Roger.Clarke/EC/AnnBibl.html#PKI

Unfortunately, HIC has ignored all the warnings.

The scheme is a naive application of ill-conceived and dangerous
technology.  It fails dismally because it doesn't reflect the interests of
business enterprises in the health care sector, or of the tens of thousands
of health care professionals who are intended to be caught up in it, or of
the millions of patients nationwide who are somehow expected to participate.

                              _________


A small amount of information is at:
http://www.hesa.com.au/about_hesa.htm

It states that the scheme "authenticates the identity of the prospective
Healthcare Location or Healthcare Individual User".  A Healthcare
Individual (HCI) is defined as "a *person* providing *or receiving*
healthcare and associated services within the Australian health sector"
(Healthcare Individual Certificate Policy at 1.1, p.8, my emphases).  It is
therefore claimed to be applicable to health care professionals *and* to
every patient in the country.

In most health care organisations, communications are driven by
administrative staff.  It is unclear whether they are to have their own
keys, or whether they are instead expected to use a generic 'location' key.

The process of authentication is a "100 point check", and "the HeSA RA may
require a [person] to attend a personal interview for the purposes of
identity verification" (3.1.9, p.44 and App. B, pp.77-81).  This appears to
apply to both health care providers *and* to patients.  So it appears that
a strongly authenticated identity is shortly to be a pre-requisite for a
person to be permitted to exchange messages with health care organisations.

In regard to key generation, the 'About' page states that "The Health
eSignature Authority then distributes the Digital Key pairs";  but it does
not explain where they are generated.  HeSA describes itself as a
Registration Authority (RA) rather than a Certification Authority (CA).  So
on that basis it seems unlikely that HeSA would invest in the capability to
generate keys, and would instead rely on the services of the Certification
Authority - Baltimore Certificates Australia Pty Limited (CAPL), which
could generate them, and pass them to HeSA, which would in turn pass them
on to the individuals and companies who are meant to use them.

However, deep down in the Policy Document is the statement that "Subscriber
Keys will be generated by the HeSA RA" (6.1.1, p.67);  so presumably HeSA
is investing after all.

The actual set of services provided does not appear to be explained,
although the structure of the Fees Schedule provides some clues:
http://www.hesa.com.au/pki_fees.htm

Nor does there appear to be any general guidance as to the purposes of the
exercise, nor to who is meant to use the keys and for what purposes.

There also appears to be no straightforward guidance as to the manner in
which risk is to be apportioned among the HIC, HeSA, Baltimore/CAPL, the
'key-owner', and the parties that may rely on it.

Anyone who considers participating in this scheme would be well-advised to
read the Gatekeeper Individual Healthcare Agreement (App. D, pp.83-90)
really, really carefully.  Among other concerns, it is not clear what, if
any, consultation took place with stakeholder representatives and public
interest advocates in the preparation of this document (or indeed in any
other aspect of the scheme's design).

To understand what the proposition is, a series of documents needs to be
downloaded, studied and absorbed.  The documents amount to 2MB of PDF
containing several hundred pages of text, plus 4 further documents from
Baltimore / CAPL / Certificates-Australia.

The requirement to download these documents is not just nominal.  There is
an express requirement that "the [health-care individual] must first make
an informed choice by obtaining, reading and understanding the CP and CPS
under which HCI Keys and HCI Certificates are issued" (3.1, p.43).

Tens of thousands of professionals (let alone millions of patients) simply
won't read 100 pages of IT-technical bumff.  So the conclusion has to be
that there will be no informed choice, and hence no consent, even by any
people who are bold and foolhardy enough to acquire keys and certificates
using this process.

"The Private Keys of ... a Subscriber will be activated by cryptographic
software, following the successful completion of a login process that
validates an authorised user" (6.2.7, p.69).  This leaves wide open the
question of what protections will exist on the workstations and servers
that store and permit the invocation of individuals' private keys.  For a
discussion of the huge security risks associated with the storage of
private keys on commodity workstations, see:
http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html#PteKey

The people who are nominally 'bound' to the key (e.g. hospital CEOs?,
medical practice managers?, doctors, nurses, and apparently even patients)
will be exposed to a number of risks relating to their private-key(s):
-   mis-use by Baltimore or its staff and contractors (if they have them);
-   mis-use by HeSA or its staff and contractors;
-   mis-use by any party that breaches the security of storage of
    Baltimore (if they have them), HeSA, or the key-holder itself;
-   mis-use by any party that gains access to the private-key while it is
    in transit from Baltimore to HeSA (if that occurs), or from HeSA to the
    key-owner.  The second of those links is by Registered Post (and
    perhaps some additional channels).

Very limited privacy protections apply (2.8, pp.35-40).  It is not apparent
that any public consultations have ever been held.  And any attempt to rely
on the scheme's Gatekeeper accreditation fails dismally in regard to
privacy, because the GPKA held no public consultations, and the privacy
advocate (myself) resigned from that body because of its abject failure to
address the privacy concerns despite 2 years of submissions by myself and
my predecessor.

Having been established as a company, HeSA is not subject to the public
sector provisions of the Privacy Act, and neither is Baltimore.  The
original Gatekeeper accreditation process requires simply that the
organisation applying for accreditation commit to complying with the
private sector Information Privacy Principles.

HeSA and CAPL may become subject to the private sector provisions of the
Privacy Act when the recent amendments come into force at the end of 2001.
But those provisions are a pale reflection of the privacy protections that
were thought to be needed in about 19*70*, and completely fail to reflect
developments in technology and organisational practice over the last 30
years, including public key cryptography (which was invented in 1976).

Yet worse, the December 2000 amendments to the Privacy Act were an
*anti*-privacy statute.  They're riddled with exemptions and exceptions
that have the effect of actually legitimising privacy-invasive activities
by corporations.  Here is a succinct statement on that matter:
http://www.anu.edu.au/people/Roger.Clarke/DV/SenatePBSub2000.html
and here is a more comprehensive analysis:
http://www.anu.edu.au/people/Roger.Clarke/DV/PAPSSub0001.html

I understand that the GPKA, some months ago, and just prior to being
reduced to a mere advisory committee, may have committed to some further
general principles relating to privacy.  It is unclear whether those
principles have any standing whatsoever.  Even if they do, it is unclear
whether and when they come into force, and whether they apply to HeSA's and
CAPL's activities, either now or at any time in the future.

Quite expressly, "pseudonymous names are not supported" (3.1.2, p.43).  Any
protected witness, abused spouse or undercover security operative that
works in the health care sector, or that ever needs treatment, will
therefore be refused permission to use any name other than the one on
whatever documents HeSA decides it will accept.

The name to be used is "the common name" (whatever that means).  The
documents state that common name "includes ... first name, middle initial,
surname and customer number" (without seeming to explain what 'customer
number' means in this context).  It further states that "state and country
[are] part of the Distinguished Name".

This suggests that the first applicant with a particular name within a
State gets it, and that other people with the same name don't *exist* as
far as this scheme is concerned, unless each of them has some 'customer
number' that breaks the synonym.  Note that the scope of the name-space
involved is the entire Australian population ...

                               _________


Conventional X.509v3-based public key infrastructure is a crude tool that
breaches a whole series of public policy requirements.  The HIC's scheme is
a naive application of that technology.  It would be remarkable if the
nation's health care professionals and business managers were prepared to
participate in it.  And it would be seriously to their detriment if they
did so.


Roger Clarke              http://www.anu.edu.au/people/Roger.Clarke/

Xamax Consultancy Pty Ltd, 78 Sidaway St, Chapman ACT 2611 AUSTRALIA
                Tel: +61 2 6288 1472, and 6288 6916
mailto:Roger.Clarke@xamax.com.au            http://www.xamax.com.au/

Visiting Fellow                       Department of Computer Science
The Australian National University     Canberra  ACT  0200 AUSTRALIA
Information Sciences Building Room 211       Tel:  +61  2  6125 3666