Developing interoperable e-government solutions in Hungary


Published on

In 2005 we presented the Hungarian Electronic Public Administration Interoperability Framework on the eGOV INTEROP'05 Conference. In this paper we show the activities leading toward the realization of this project. We describe the legal background, the cooperation between governmental, private and educational parties and a case study of an interoperability test between electronic signature applications. In the last part we explain the future possibilities in the field of e-governmental interoperability.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Developing interoperable e-government solutions in Hungary

  1. 1. Developing interoperable e-government solutions in Hungary Krasznay Csaba BME Centre of Information Technology Szabó Áron BME Centre of Information Technology
  2. 2. Contents <ul><li>Legal background </li></ul><ul><li>Regulations in connection with interoperability and security </li></ul><ul><li>Interoperability test on the field of electronic signatures </li></ul>
  3. 3. Legal regulation <ul><li>Legal regulation </li></ul><ul><li>Act XXXV of 2001 on Electronic Signatures (1999/93/EC) </li></ul><ul><li>Act LV of 2004 on modification of Act XXXV of 2001 on Electronic Signatures </li></ul><ul><li>Act CXL of 2004 on the general regulation of the administrative authority process and services (since 1 November 2005) </li></ul>
  4. 4. Act CXL of 2004 <ul><li>The Act CXL of 2004 fundamentally changes the operation of Hungarian public administration </li></ul><ul><li>It regulates the operation of electronic administration </li></ul><ul><li>There are 5 IT related executive orders in connection with the Act </li></ul><ul><li>Many technical specifications were made </li></ul><ul><li>The governmental regulation 195/2005. (IX. 22.) is about the security and interoperability of IT systems in the public administration </li></ul>
  5. 5. Governmental regulation 195/2005. (IX. 22.) <ul><li>The 4th part deals with the requirements of quality management </li></ul><ul><li>This part is based on ISO 9001 and ISO 17799 standards </li></ul><ul><li>It orders the execution of risk assessment </li></ul><ul><li>E-governmental functions must be enumerated into security classes </li></ul><ul><li>Outsourcing is accepted </li></ul>
  6. 6. Governmental regulation 195/2005. (IX. 22.) <ul><li>The 5th part deals with the security requirements </li></ul><ul><li>It demands SSL connection, a unique identifier and time stamping during the authentication phase </li></ul><ul><li>Logs, BCP, backup and archiving must be ensured in e-government systems </li></ul><ul><li>Importance of archiving of electronic documents is mentioned emphatically </li></ul><ul><li>AV software must be used in these systems </li></ul><ul><li>Development of access and physical security is also the part of the regulation </li></ul>
  7. 7. Governmental regulation 195/2005. (IX. 22.) <ul><li>Interoperability questions appear in the 6th part </li></ul><ul><li>The government realized the threat of usage of different data format in e-government systems </li></ul><ul><li>Usage of open international standards is recommended </li></ul><ul><li>On the whole this is an important and long-waited regulation </li></ul>
  8. 8. Technical recommendations <ul><li>The Ministry of Informatics and Communications also published some technical recommendations to ensure interoperability in the public procedures </li></ul><ul><li>These recommendations deal with the </li></ul><ul><ul><li>format of electronic signatures, </li></ul></ul><ul><ul><li>electronic signature policies, </li></ul></ul><ul><ul><li>certificate policies, </li></ul></ul><ul><ul><li>the structure of certificates , </li></ul></ul><ul><ul><li>t ime stamps , </li></ul></ul><ul><ul><li>mutual identification </li></ul></ul><ul><ul><li>and the interoperability standards catalogue. </li></ul></ul>
  9. 9. Cooperation between public and private actors <ul><li>Most of these recommendations are developed with the help of international standards </li></ul><ul><li>The recommendation about the format of electronic signatures was developed by an independent association with the support of the Ministry </li></ul><ul><li>The members of Hungarian Association for Electronic Signatures (MELASZ) formed a workgroup to make an interoperable e-signature format </li></ul><ul><li>This workgroup contained the most significant Hungarian application developers who have a solution for this field </li></ul><ul><li>Their agreement was converted to the official recommendation. </li></ul>
  10. 10. Independent interoperability test <ul><li>Budapest University of Technology and Economics Information Technology Innovation and Knowledge Centre offered its laboratory for the interoperability test </li></ul><ul><li>All participants accepted the laboratory as an independent party </li></ul><ul><li>MELASZ can give certifications for the companies who fulfills the interoperability requirements </li></ul><ul><li>This certificate is de facto accepted by the public administration </li></ul><ul><li>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) </li></ul>
  11. 11. The past few years... <ul><li>Technical regulation </li></ul><ul><li>IETF: S/MIME v3.0 (RFC 2633), S/MIME v3.1 (RFC 3851) </li></ul><ul><li>W3C , IETF: XML electronic signature, XMLDSig (RFC 3275) </li></ul><ul><li>ETSI , W3C: XAdES (TS 101 903 v1.2.2, v1.3.1) </li></ul><ul><li>CEN: requirements (CWA 14170, CWA 14171) </li></ul><ul><li>pkiC, Bridge-CA, European Bridge-CA, eESC, MELASZ Ready </li></ul><ul><li>interoperability tests at standardization bodies </li></ul><ul><li>XMLDSig: IETF , W3C </li></ul><ul><li>XAdES: ETSI </li></ul>
  12. 12. Interoperability test <ul><li>IETF and W3C: XML-Signature Interoperability </li></ul><ul><li> </li></ul><ul><li>W3C XML-Signature Syntax and Processing </li></ul><ul><li>IETF RFC 3275 </li></ul><ul><li>ETSI: XML Advanced Electronic Signature </li></ul><ul><li> </li></ul><ul><li>ETSI TS 101 903 v1.2.2 (ETSI TS 101 903 v1.3.1) </li></ul><ul><li>Hungarian Association for Electronic Signature </li></ul><ul><li>(Magyar Elektronikus Aláírás Szövetség: MELASZ Ready) </li></ul><ul><li> </li></ul>
  13. 13. Interoperability test <ul><li>Data of examination </li></ul><ul><li>provided by: Szabó Áron, Krasznay Csaba </li></ul><ul><li>place: BME Centre of Information Technology </li></ul><ul><li>date: 1 October 2005 – 15 November 2005 </li></ul><ul><li>tools: ASN1 Editor (Liping Dai) </li></ul><ul><li>Asn1Viewer 1.3.4 (Objective Systems Inc.) </li></ul><ul><li>XMLSpy 2006 Home Edition (Altova GmbH) </li></ul><ul><li>OpenSSL 0.9.8 </li></ul><ul><li>self-developed tool </li></ul><ul><li>participants: E-Group Magyarország Rt. </li></ul><ul><li>MICROSEC Számítástechnikai Fejlesztő Kft. </li></ul><ul><li>NetLock Kft. </li></ul><ul><li>Polysys Kft. </li></ul><ul><li>SDA Stúdió Kft. </li></ul>
  14. 14. Interoperability test <ul><li>First-round check </li></ul><ul><li>XML parser and canonicalization functions </li></ul><ul><li>Second-round check </li></ul><ul><li>well-formedness and schema (XMLDSig, XAdES) validity of XML electronic signature (XML file) </li></ul><ul><li>Third-round check </li></ul><ul><li>test-matrix (cross-match of several applications) </li></ul>
  15. 15. Interoperability test <ul><li>First-round check </li></ul><ul><li>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) c ould be problematic, therefore different hash values, digest values were provided for the same input data. </li></ul><ul><li>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. </li></ul>
  16. 16. Interoperability test <ul><li>Second-round check </li></ul><ul><li>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. </li></ul><ul><li>XMLDSig and XAdES schemas were assigned to the output of applications and the well-formedness and schema validity of these files were checked. </li></ul>
  17. 17. Interoperability test <ul><li>Third-round check </li></ul><ul><li>Outputs of several applications were used as inputs to other applications. </li></ul><ul><li>Applications must have provided „enveloping signatures” including timestamps (SignatureTimeStamp) and certificates (CompleteCertificateRefs, CertificateValues) by a „soft token” (PKCS#12 standard complied .pfx file). </li></ul><ul><li>At „initial verification” of these outputs were verified by other applications and were extended with revocation information (CRL s , OCSP responses in CompleteRevocationRefs and RevocationValues elements) after „grace period”. </li></ul>
  18. 18. Interoperability test <ul><li>Side of service provider </li></ul><ul><li>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. </li></ul><ul><li>Problems were noticed in connection with contents of data (keyUsage, extKeyUsage, settings of critical bit, cRLDistributionPoints) and schema of data (ASN.1 compliance). </li></ul>
  19. 19. Security audits <ul><li>Common Criteria </li></ul><ul><li>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?). </li></ul><ul><li>Interoperability testing </li></ul><ul><li>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?). </li></ul>
  20. 20. Thank you! <ul><li>Csaba Krasznay , M. Sc., CISA </li></ul><ul><li>research associate </li></ul><ul><li>[email_address] </li></ul><ul><li> </li></ul><ul><li>Áron Szabó , M. Sc. </li></ul><ul><li>research associate </li></ul><ul><li>[email_address] </li></ul><ul><li> </li></ul><ul><li>Budapesti University of Technology and Economics </li></ul><ul><li>Centre of Information Technology </li></ul><ul><li>H-1117, Budapest </li></ul><ul><li>Magyar tudósok körútja 2. </li></ul>Contacts