1 / 20

Developing interoperable e-government solutions in Hungary

Developing interoperable e-government solutions in Hungary. Krasznay Csaba BME Centre of Information Technology Szabó Áron BME Centre of Information Technology. Contents. Legal background Regulations in connection with interoperability and security

andrew
Télécharger la présentation

Developing interoperable e-government solutions in Hungary

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Developing interoperable e-government solutions in Hungary Krasznay Csaba BME Centre of Information Technology Szabó Áron BME Centre of Information Technology

  2. Contents • Legal background • Regulations in connection with interoperability and security • Interoperability test on the field of electronic signatures

  3. Legal regulation Legal regulation • Act XXXV of 2001 on Electronic Signatures (1999/93/EC) • Act LV of 2004 on modification of Act XXXV of 2001 on Electronic Signatures • Act CXL of 2004 on the general regulation of the administrative authority process and services (since 1 November 2005)

  4. Act CXL of 2004 • The Act CXL of 2004 fundamentally changes the operation of Hungarian public administration • It regulates the operation of electronic administration • There are 5 IT related executive orders in connection with the Act • Many technical specifications were made • The governmental regulation 195/2005. (IX. 22.) is about the security and interoperability of IT systems in the public administration

  5. Governmental regulation 195/2005. (IX. 22.) • The 4th part deals with the requirements of quality management • This part is based on ISO 9001 and ISO 17799 standards • It orders the execution of risk assessment • E-governmental functions must be enumerated into security classes • Outsourcing is accepted

  6. Governmental regulation 195/2005. (IX. 22.) • The 5th part deals with the security requirements • It demands SSL connection, a unique identifier and time stamping during the authentication phase • Logs, BCP, backup and archiving must be ensured in e-government systems • Importance of archiving of electronic documents is mentioned emphatically • AV software must be used in these systems • Development of access and physical security is also the part of the regulation

  7. Governmental regulation 195/2005. (IX. 22.) • Interoperability questions appear in the 6th part • The government realized the threat of usage of different data format in e-government systems • Usage of open international standards is recommended • On the whole this is an important and long-waited regulation

  8. Technical recommendations • The Ministry of Informatics and Communications also published some technical recommendations to ensure interoperability in the public procedures • These recommendations deal with the • format of electronic signatures, • electronic signature policies, • certificate policies, • the structure of certificates, • timestamps, • mutual identification • and the interoperability standards catalogue.

  9. Cooperation between public and private actors • Most of these recommendations are developed with the help of international standards • The recommendation about the format of electronic signatures was developed by an independent association with the support of the Ministry • The members of Hungarian Association for Electronic Signatures (MELASZ) formed a workgroup to make an interoperable e-signature format • This workgroup contained the most significant Hungarian application developers who have a solution for this field • Their agreement was converted to the official recommendation.

  10. Independent interoperability test • Budapest University of Technology and Economics Information Technology Innovation and Knowledge Centre offered its laboratory for the interoperability test • All participants accepted the laboratory as an independent party • MELASZ can give certifications for the companies who fulfills the interoperability requirements • This certificate is de facto accepted by the public administration • The interoperability test and the laboratory is supported by the National Office for Research and Technology through R&D tenders (Péter Pázmány Program, Inno-cheque)

  11. The past few years... Technical regulation • IETF: S/MIME v3.0 (RFC 2633), S/MIME v3.1 (RFC 3851) W3C, IETF: XML electronic signature, XMLDSig (RFC 3275) ETSI, W3C: XAdES (TS 101 903 v1.2.2, v1.3.1) CEN: requirements (CWA 14170, CWA 14171) • pkiC, Bridge-CA, European Bridge-CA, eESC, MELASZ Ready • interoperability tests at standardization bodies XMLDSig: IETF, W3C XAdES: ETSI

  12. Interoperability test • IETF and W3C: XML-Signature Interoperability http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html W3C XML-Signature Syntax and Processing IETF RFC 3275 • ETSI: XML Advanced Electronic Signature http://www.etsi.org/plugtests/ ETSI TS 101 903 v1.2.2 (ETSI TS 101 903 v1.3.1) • Hungarian Association for Electronic Signature (Magyar Elektronikus Aláírás Szövetség: MELASZ Ready) http://www.melasz.hu/

  13. Interoperability test Data of examination provided by: Szabó Áron, Krasznay Csaba place: BME Centre of Information Technology date: 1 October 2005 – 15 November 2005 tools: ASN1 Editor (Liping Dai) Asn1Viewer 1.3.4 (Objective Systems Inc.) XMLSpy 2006 Home Edition (Altova GmbH) OpenSSL 0.9.8 self-developed tool participants: E-Group Magyarország Rt. MICROSEC Számítástechnikai Fejlesztő Kft. NetLock Kft. Polysys Kft. SDA Stúdió Kft.

  14. Interoperability test First-round check • XML parser and canonicalization functions Second-round check • well-formedness and schema (XMLDSig, XAdES) validity of XML electronic signature (XML file) Third-round check • test-matrix (cross-match of several applications)

  15. Interoperability test First-round check • At W3C/IETF and ETSI plugtests have already been turned out that canonicalization of XML files (e.g. well-handling of „white space” characters, „xmlns” attributes and parent-child elements) could be problematic, therefore different hash values, digest values were provided for the same input data. • Three sample XML document (XML file) have been developed that can check whether the given application, API (development kit) can canonicalize XML data well or not. Outputs were examined at low-level (bit level) in the laboratory.

  16. Interoperability test Second-round check • The structure of outputs must have been in conformity with ETSI (XAdES) standard, „required” elements must have existed, „optional” elements may have existed in XML electronic signature. Some extensions, notes were laid down in HAES (MELASZ) documents to conduce interoperability of applications. • XMLDSig and XAdES schemas were assigned to the output of applications and the well-formedness and schema validity of these files were checked.

  17. Interoperability test Third-round check • Outputs of several applications were used as inputs to other applications. • Applications must have provided „enveloping signatures” including timestamps (SignatureTimeStamp) and certificates (CompleteCertificateRefs, CertificateValues) by a „soft token” (PKCS#12 standard complied .pfx file). • At „initial verification” of these outputs were verified by other applications and were extended with revocation information (CRLs, OCSP responses in CompleteRevocationRefs and RevocationValues elements) after „grace period”.

  18. Interoperability test Side of service provider • Key point of interoperability of applications was the ITU-T X.509 compliance of issued certificates, CRLs, RFC 2560 compliance of OCSP responses, RFC 3161 compliance of timestamps of service providers. • Problems were noticed in connection with contents of data (keyUsage, extKeyUsage, settings of critical bit, cRLDistributionPoints) and schema of data (ASN.1 compliance).

  19. Security audits Common Criteria • A security audit based on Common Criteria methodology must examine whether functions inside the product are strong enough or not (e.g. is it still enough to use SHA-1 hashing algorithm, or should we use the stronger SHA-256 or SHA-512 instead?). Interoperability testing • The main goal of interoperability testing is to examine the outputs, the interfaces of the product which can be seen by another application (e.g. does the application provide the standardized processing of hashing algorithm SHA-1 or not?).

  20. Thank you! Contacts Csaba Krasznay, M. Sc., CISA research associate krasznay@ik.bme.hu www.krasznay-csaba.com Áron Szabó, M. Sc. research associate aron@ik.bme.hu www.szabo-aron.hu Budapesti University of Technology and Economics Centre of Information Technology H-1117, Budapest Magyar tudósok körútja 2.

More Related