Presentation on theme: "Developing interoperable e-government solutions in Hungary Krasznay Csaba BME Centre of Information Technology Szabó Áron BME Centre of Information Technology."— Presentation transcript:
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 Interoperability test on the field of electronic signatures
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)
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
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
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
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
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, time stamps, mutual identification and the interoperability standards catalogue.
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.
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)
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
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/
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.
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)
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.
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.
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”.
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).
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?).
Thank you! Csaba Krasznay, M. Sc., CISA research associate email@example.com www.krasznay-csaba.com Áron Szabó, M. Sc. research associate firstname.lastname@example.org www.szabo-aron.hu Budapesti University of Technology and Economics Centre of Information Technology H-1117, Budapest Magyar tudósok körútja 2. Contacts
Your consent to our cookies if you continue to use this website.