It is my opinion that there is no such thing as a perfect solution for
security that this TC can adopt based on technology only. But just as is the
case of messaging protocols such as HTTPS, ebXML, SOAP, there must exist
options for each court to determine what security model will work best for
them. These options will be affected by the laws that each state has
implemented regarding digital signatures, imaged signatures, implied
signatures, ucc signatures, and how each state's laws are affected by the
Federal E-Sign law, and how each state's laws are affected by the Uniform
Electronic Transaction Act 'UETA'. The following link will guide the reader
through various pages of data relating to different laws various states and
some countries have implemented.
http://www.pki-page.org . From this link you can also find the link to the
ABA description of digital signatures.
http://www.abanet.org/scitech/ec/isc/dsg-tutorial.html
Note on UETA:
------------------
UETA is important because it
- establishes the legal equivalent of electronic records and signatures,
eliminating the requirement to print and store hard copies and reducing
storage costs
- requires the retention of the electronic original in a manner that allows
for later use and retrieval, which means migration issues must be addressed
- establishes minimum standards for when information is considered legally
sent or received in electronic form
-------------------
I have found this law firms links to be of value over the years in some of
these areas: http://www.bakernet.com/ecommerce/
Because of these various complexities of laws, we have pushed to make sure
that our EFSP and EFM can deal with multiple Hash functions and different
ways to take advantage of digital signatures and deal with some of these
laws. We currently us X.509 certificates for individual signatures and
digital locks.
In the Atlanta Georgia meeting of the TC, I presented our use of the digital
lock as an extension of the LegalXML envelope and why. We use this digital
lock in addition to individual digital signatures in the Utah
implementation. The digital lock is a method of binding an implied
signature (whether it is an attorney submitting a filing or a judge issuing
an order), together with the documents so that the evidence of the
transaction is permanently locked creating evidence which can later be used
against disputes that may occur. When the information about the order
migrates from the approval event to the database, the event is trapped
within the envelope and locked so that the information stored in the
database can be audited and verified later against the envelope.
The security event we are worried about here is the process of a Judge
approving a documentation containing an order that he/she is viewing. The
real question of security then becomes how long before the approval event is
locked and what is the process of trapping that information electronically
so that proper evidence exists, cannot be tampered with, and can be stored
for an undetermined amount of time.
Again the issues are:
- what is the process of electronically trapping the event
- are their any holes in the process where someone could alter the event
before it is digitally locked
- how is the digital lock and the information stored so that it can be
verified at a later date
Regarding the security of individual signatures: Most Certificate
Authorities policies say that a private key is compromised and should be
revoked if the user allows the key to be out of their control. This is very
difficult to achieve since most people rely on their IT staff to order,
install, and manage their keys and their computers. There are several
points in this model where the keys are out of the control of the Judge
because if it is installed in their browser any IT staff with the right
authority can get to the key especially if they helped the Judge order the
key. At this point it is nothing more than a username and password.
Regarding the Digital Lock: We have implemented a digital lock that binds
the user ID, IP address, the time the submission was created, and all
documents embedded into the envelope together with a digital signature of
the EFPS server that created the envelope. The weakness here is that
someone can break-in with some else's user name and password and create
something for submission. This weakness is inherent to any system that uses
a UserName and Password even digital signatures in many cases.
Regarding the DSS: It seems to me that the same weakness occurs here as any
system that requires a UserName and Password to log-in, upload a document to
have a signature applied to it, and then send it to the courts.
It is my impression that the digital lock is less expensive and easier to
manage than the DSS concept.
The value of an individual digital signature, digital lock, or a DSS is that
evidence is created which electronically binds data together, hopefully into
a single entity for electronic storage, and is stored intentionally as long
term evidence.
The only way to improve the security model even with these digital
signature/locking concepts, is by the author of the event to review the data
after the digital signature or digital lock is applied and the database is
uploaded. Even this process has some weaknesses, but we have significantly
increased the level of security and it is far greater than a paper system.
When we create a digitally signed receipt from the courts for a submission
that goes back to the attorney or judge, we either include the original
data that was submitted or we include the digital digest (hash) of the data.
It provides the originator to audit the information for validity.
I hope this helps.
Dallas
----- Original Message -----
From: "jmessing" <jmessing@law-on-line.com>
To: <legalxml-courtfiling@lists.oasis-open.org>
Cc: <ajensen@occourts.org>
Sent: Sunday, May 11, 2003 2:19 PM
Subject: [legalxml-courtfiling] Re: [courtfiling-process] Security of court
orders
> <JM>[Note: For those not comfortably familiar with the technology being
discussed, please visit http://www.law-on-line.com/tutorial1.htm for a
description of encryption processes generally. Signatures and hashes begin
at http://www.law-on-line.com/tutor
> ial3.htm, and there is a glossary of terms available. An interactive quiz
applies the concepts to examples and hypotheticals. Some people who have
used it reported finding the explanations at the site extremely useful to
get a handle on the processes in
> volved.]
>
> As I understand the described system by John Aerts, Gary Poindexter, and
Jim Keane, a hash of an order is obtained and stored in a database. The
relational association in the database between a username and a stored hash
is considered a "signature" sin
> ce the judge provided a password to submit the order to the system
understanding that the submission was an act of signature and the
association between the user's identity and the hash of an order in the
database evidences the intended signature.
>
> I agree with Charles Gillam of ContentGuard in his posting where he points
out "I have heard of persons entering systems and placing unauthorized
material there." Other responses I have received stress the vulnerability of
the database and the network a
> s a source of concern, and the ease of spoofing a judge's IP address (if
IP addresses are used) was also specifically mentioned as another potential
security threat by one knowledgeable expert...
>
> The security of the database against attack is important since as Gary
Poindexter points out, the hash or message digest can be generated by anyone
through use of the hashing algorithm, which unlike encryption keys, is
available generally to anyone. Wit
> h it, anyone can generate a hash of a file. SHA-1 referenced by John Aerts
is a commonly used hashing algorithm. The intentionally free availability of
hashing resources creates a possibility of an intruder replacing a genuine
hash in the database with
> another one of his or her making, thus tricking the system into believing
a judge signed an order other than the one originally submitted.
>
> Such an attack requires an ability to break-in to the network and database
to effectuate the substitution.
>
> There is a recent case documented of such an actual break-in and
alteration of court records in Riverside, CA, which led to the conviction of
two consultants. They pled guilty and were sentenced to nine years apiece.
>
> The incident is cause for concern about the architecture and process
described by John Aerts, Gary Poindexter, and Jim Keane.
>
> Here is some of the media web coverage.
>
> </JM>
>
> ==========================================================================
>
> From: http://www.sans.org/newsletters/newsbites/vol5_6.php
>
> "-- Two Men Sentenced for Altering Data in California Court Computer
System
>
> (7 February 2003)
>
> Two hackers have pleaded guilty to breaking into Riverside County (CA)
court computer system and altering data to make it appear charges had been
dismissed in a number of cases, including one against one of the hackers.
The two obtained access to the sy
> stem through a password one of them had copied while working as an outside
consultant to a local police department. William Grace and Brandon Wilson
were each sentenced to nine years in prison.
http://www.msnbc.com/news/870163.asp?0dm=C17LT
>
> [Editor's Note (Ranum): {<JM>redacted</JM>} (Grefer): This incident may
serve as a timely reminder to our readers to implement (and test) a policy
of regular password changes.]"
>
> ================================================
>
> <JM>Some of the details of how the attacks were made and discovered can be
found at http://www.sachitechcops.com/news1115.htm
>
> I have excerpted from the story by William Overend, of the Los Angeles
Times:
>
> </JM>
>
> "Most recently, the San Diego task force was called to help solve a
Riverside County case that had court officials puzzled. Employees had
noticed that bail amounts had been reduced to zero in some cases and future
court dates had been deleted.
>
> Investigators logged on to the computer system and began watching it
around the clock, said the task force leader, Michael Groch.
>
> 'The investigators could see the suspect activity while it was taking
place,' Groch said. 'Eventually, it turned out to involve a man with
considerable computer skills.'
>
> According to investigators, Brandon Wilson and William Grace cracked into
the county's court computer system 72 times, altering Wilson's records and
those of four other people to make it appear that their cases had been
closed.
>
> Charges included possession of illegal drugs and weapons, failure to
appear in court, driving under the influence, and manufacturing and
importing weapons. Officials say Wilson changed the records to show that the
charges had been dismissed.
>
> Wilson also changed drug and gun charges for one woman, and traffic
charges for a man, investigators said. Wilson also was charged with altering
the records of an accused embezzler and another man charged with driving
under the influence.
>
> Facing 216 felony counts each since their arrest in June, Wilson and Grace
have pleaded not guilty and await trial in Riverside County."
>
> <JM>[Since the time the article was written they reportedly pled guilty
and were sentenced. See earlier quoted article from SANS.]</JM>
>
> "Morgester said one problem in past computer crime cases has been a
history of light sentences. In addition, many prosecutors are reluctant to
pursue them because they are often complex and pose difficult jurisdictional
problems. A criminal can touch vi
> ctims thousands of miles away.
>
> 'An old adage in law enforcement is, 'If it doesn't bleed, it isn't a
crime,' Morgester said.
>
> As with the state's other task forces in San Jose, Napa, Los Angeles and
San Diego, the Sacramento office is a mix of top electronics experts and
cops pulled from other duties."
>
> <JM>[The story goes on to note the paucity of criminal investigators for
such cases, which raises a possibility of other, undetected such
cases.]</JM>
>
> "By Dec. 31 this year, we estimate we will have 12,000 identity theft
cases in Los Angeles alone. We have 11 investigators to handle them." .
>
>
============================================================================
===
> <JM>Assuming proper security of a single court's database, the EFSP model
envisioned by LegalXML which is being pursued more aggressively in this era
of budgetary shortfalls, greatly complicates the security issues. Not only
do courts need to be concern
> ed with their own security, they need to be mindful of the security of the
EFSP's with whom they interact on a regular basis (which may be multiple
EFSP's where interoperable vendor systems access the court) and of any
private lawfirms whose CMS systems
> may be automatically be updated by objects that communicate between an
EFSP and an outside party. An attacker may be able to find a back door into
the network at any vulnerable point and work backwards into the systems to
reach the databases. The secur
> ity issues are likely to increase dramatically as the infrastructure
develops and matures.
>
> I am the liasion between the LegalXML CourtFiling TC and the DSS (Digital
Signature Services) TC of Oasis. A digital signature service includes a web
service that affixes a digital signature on behalf of a requestor. This is
much like the hash + databas
> e example that is discussed in the postings from John Aerts, Gary
Poindexter, and Jim Keane, but it adds an additional feature. Not only is
the hash extracted and saved, but the hash is encrypted with a private
asymmetric key. (An encrypted hash is the
> digital signature itself).
>
> An added advantage is that an encrypted hash is much harder to forge than
a hash itself because one generally lacks the private encryption key, which
unlike the hashing algorithm, is not freely available but is unique, guarded
and hidden.
>
> In fact if one reads the SHA-1 description closely, SHA-1 is designed
primarily as a basis for digital signature creation and verification, and
the use of SHA-1 as a substitute for digital signatures is not an intended
use. See John Aert's citation of a
> uthority:
>
> 180-1
>
> Secure Hash Standard (SHS) -- 95 Apr 17
> - To specify a Secure Hash Algorithm to be used by both the transmitter
and intended receiver of a message in computing and verifying a digital
signature.
>
> http://www.itl.nist.gov/fipspubs/fip180-1.htm
>
> Again, for those to whom the technology discussion is confusing, please
consider visiting the tutorial that begins at
http://www.law-on-line.com/tutorial1.htm
>
> Mo Abdulaziz' court, the Arizona Court of Appeals, Division Two, captures
and saves the hash and digitally signs submissions for this very reason.
>
> It can be relatively easy transition from a hash only system to a DSS
that also uses digital signatures, and the potential security advantages may
be very important. There are other enhancements and configurations possible,
including having the Clerk's
> office act as a DSS in its historic role of authentication of judicial
orders, but they can be discussed off-line if anyone is interested in
pursuing such a discussion
>
> A DSS avoids having to have end users each obtain, master, and use their
own encryption keys and digital certificates, while still using digital
signatures for security. It occupies an area somewhere between a hash-only
system and full blown pki. Someth
> ing like a DSS is probably indispensible for EFSP's, who may be far more
attractive litigation targets than a court itself, which may (but not
always) benefit from sovereign immunity against liability.
>
> The other part of the security picture is a continuing analysis of the
threat and attack points to compromise a network and access the database. In
this regard, the determination noted by Jim Keane of the DOJ that the
hash-only practice of the federal c
> ourts did not compromise the secure DOJ network is more a statement about
the interface between the two and the overal security of the DOJ network
than it may be an approval of a particular hashing and storage method used
by the federal courts.
>
> I think the security issues outlined in the postings, including this one,
deserve top priority by LegalXML Court Filing and this subcommittee in
particular.
>
> Thanks and as always best regards.
>
> -----Original Message-----
> From: Aerts, John F. [mailto:jfaerts@lasd.org]
> Sent: Thursday, April 17, 2003 7:28 AM
> To: 'Poindexter, Gary W (BearingPoint)'; 'jkeane';
jmessing@law-on-line.com; 'Gilliam, Charles'; 'John Greacen'; 'Efiling
Process Models Subcommittee'
> Cc: 'Michael Greenwood (E-mail)'; 'Robert Borochoff (E-mail)'
> Subject: RE: [courtfiling-process] Security of court orders
>
> I don't know which one was used but FIPS 180-1 was referenced in the court
managment published specifications. And 198 was only recently released.
>
>
>
> I would hope that it is possible to go forward with both. 180-1 for the
signature and 198 for the instance (message) or just 198 if it can
accomplish both.
>
>
>
> JA
>
>
>
>
>
> 180-1
>
> Secure Hash Standard (SHS) -- 95 Apr 17
> - To specify a Secure Hash Algorithm to be used by both the transmitter
and intended receiver of a message in computing and verifying a digital
signature.
>
> http://www.itl.nist.gov/fipspubs/fip180-1.htm
>
>
>
>
> 198
>
> The Keyed-Hash Message Authentication Code (HMAC), 2002 March.
> -This standard describes a keyed-hash message authentication code (HMAC),
a mechanism for message authentication using cryptographic hash functions.
HMAC can be used with any iterative Approved cryptographic hash function, in
combination with a shared s
> ecret key. The cryptographic strength of HMAC depends on the properties of
the underlying hash function. The HMAC specification in this standard is a
generalization of Internet RFC 2104, HMAC, Keyed-Hashing for Message
Authentication, and ANSI X9.71, Ke
> yed Hash Message Authentication Code.
>
>
> http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf
>
> -----Original Message-----
> From: Poindexter, Gary W (BearingPoint)
[mailto:gpoindexter@bearingpoint.net]
> Sent: Thursday, April 17, 2003 5:27 AM
> To: 'jkeane'; jmessing@law-on-line.com; 'Gilliam, Charles'; 'John
Greacen'; 'Efiling Process Models Subcommittee'
> Cc: 'Michael Greenwood (E-mail)'; 'Robert Borochoff (E-mail)'
> Subject: RE: [courtfiling-process] Security of court orders
>
> The "hash total" to which Jim refers is an electronic signature. It allows
others to validate that document/file content is as produced (i.e. not
modified in any way) without unnecessarily encrypting the document/file
content. It's like a big checksum t
> hat requires a key for generation. A key is required to calculate the
electronic signature. This works when:
>
>
>
> 1) Those who must validate the document content as being authentic have
access to a key
>
> 2) Those who must validate the document content as being authentic have
access to the author's generated electronic signature for each document for
comparison to the key attached to the file. For very large documents this
can be much more efficient than
> securing a key or key pair or constantly downloading copies of the
original document.
>
>
>
> gary
>
> -----Original Message-----
> From: jkeane [mailto:jik@jkeane.com]
> Sent: Wednesday, April 16, 2003 11:48 PM
> To: jmessing@law-on-line.com; 'Gilliam, Charles'; 'John Greacen'; 'Efiling
Process Models Subcommittee'
> Cc: 'Michael Greenwood (E-mail)'; 'Robert Borochoff (E-mail)'
> Subject: RE: [courtfiling-process] Security of court orders
>
> CAT, cited below is a Committe of the US Judicial Conference. The approved
the Federal CMS/ECF system and judges' use of it in chambers for
electronically file orders. Two factor came up in my review of the Federal
system for the USDOJ 1) the Judges ac
> cepted the use of ID and password as a "signature" 2) the Officially
filed document is a PDF with some sort of hash total to determine if anyone
has tampered with the document, 3) the National Security Agency approved the
AOUSC system for interface wit
> h the highly secure DOJ system.
>
>
>
> Hope this helps...
>
>
>
> JimK
>
>
>
> James I. Keane
>
> JKeane.Law.Pro
>
> 20 Esworthy Terrace
>
> North Potomac MD 20878
>
> 301-948-4062 F: 301-947-1176 (N.B.: NEW FAX NUMBER)
>
> www.jkeane.com
>
>
>
> Co-Author and Annual Update Editor of Treatise: Litigation Support
Systems, An Attorney Guide 2nd Ed. (WestGroup, 1992, updated through 2002)
>
> -----Original Message-----
> From: John Messing [mailto:jmessing@law-on-line.com]
> Sent: Wednesday, April 16, 2003 6:05 PM
> To: jkeane; 'Gilliam, Charles'; 'John Greacen'; 'Efiling Process Models
Subcommittee'
> Cc: Michael Greenwood (E-mail); Robert Borochoff (E-mail)
> Subject: RE: [courtfiling-process] Security of court orders
>
> I have sent a request for comment to some lists I belong to as well. The
responses are very interesting. I have gotten a few back that request
further information about the nature of the connection between the database
and the judge's chamber; i.e., if
> it is IP or other. Can this information be provided? Thanks.
>
> -----Original Message-----
> From: jkeane [mailto:jik@jkeane.com]
> Sent: Wednesday, April 16, 2003 7:35 AM
> To: 'Gilliam, Charles'; 'John Greacen'; 'Efiling Process Models
Subcommittee'
> Cc: Michael Greenwood (E-mail); Robert Borochoff (E-mail)
> Subject: RE: [courtfiling-process] Security of court orders
>
> I recall the Commitee on Automation and Technology considered this issue.
I'm copying some of the AOUSC folks to see if there is any background
material that might help.
>
>
>
> Jim Keane
>
>
>
> James I. Keane
>
> JKeane.Law.Pro
>
> 20 Esworthy Terrace
>
> North Potomac MD 20878
>
> 301-948-4062 F: 301-947-1176 (N.B.: NEW FAX NUMBER)
>
> www.jkeane.com
>
>
>
> Co-Author and Annual Update Editor of Treatise: Litigation Support
Systems, An Attorney Guide 2nd Ed. (WestGroup, 1992, updated through 2002)
>
> -----Original Message-----
> From: Gilliam, Charles [mailto:Charles.Gilliam@CONTENTGUARD.COM]
> Sent: Wednesday, April 16, 2003 10:06 AM
> To: John Greacen; Efiling Process Models Subcommittee
> Subject: RE: [courtfiling-process] Security of court orders
>
> "The only way in which to circumvent this system is by bribing a member of
the judge's staff to submit a forged order to the system."
>
>
>
> That statement may be a bit bullish. I have heard of persons entering
systems and placing unauthorized material there.
>
>
>
> Still, the statement "I believe that the issue John is so concerned about
is adequately addressed by this process" could be true. It is a matter of
the level of risk you want to accept. It seems a fair question to probe the
means employed by the system
> to prevent unauthorized deposit of information. Maybe those means are
adequate or maybe there is room for improvement. What is adequate could
depend on the type of the order and what was adequate yesterday may not be
adequate tomorrow.
>
>
>
> --Charles
>
>
>
> -----Original Message-----
> From: John Greacen [mailto:john@greacen.net]
> Sent: Wednesday, April 16, 2003 00:04 AM
> To: Efiling Process Models Subcommittee
> Subject: [courtfiling-process] Security of court orders
>
> On the last conference call, John Messing insisted that the work of this
subcommittee could not proceed further until the issue of the security of
judges' orders was adequately addressed. John is concerned that electronic
judicial orders will be forged
> and criminals will be released from jail or prison as a result.
>
>
>
> The federal court efiling system, and most state and local systems, have
solved this problem by treating the electronic record contained in the
court's data base to be the official judge's order. The system can
guarantee the authenticity of these elect
> ronic orders because it will not accept orders coming from any address
except the judge's chambers. Persons wishing to verify the legitimacy of a
purported order can go online, access the court's electronic data base and
view the official order there.
> The court advises law enforcement and correctional personnel to check
orders in that fashion; they should not rely on a transmitted or printed
copy of such an order. This process provides security far exceeding
anything available in the paper world to
> day. The only way in which to circumvent this system is by bribing a
member of the judge's staff to submit a forged order to the system. That
risk is minimal.
>
>
>
> I believe that the issue John is so concerned about is adequately
addressed by this process.
>
>
>
> John M. Greacen
>
> Greacen Associates, LLC
>
> HCR 78, Box 23
>
> Regina, New Mexico 87046
>
> 505-289-2164
>
> 505-780-1450 (cell)
>
>
>
>
>
>
****************************************************************************
**
>