egovinterop2006 krasznay

							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


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!
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.