[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legalxml-courtfiling] Re: [courtfiling-process] Security of court orders
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) > > > > > > **************************************************************************** ** >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]