Responsive image
de
en

Specification CardInfo-File-Test

Syntax

TestcaseSyntax Check
Test IDS-1
Description

This test case ensures that the uploaded CardInfo-File is syntactically correct.

The syntax of the uploaded CardInfo-File is checked by means of an XML-schema validation against the specified CardInfo.xsd.

References[CardInfo.xsd]
[eCard-4]Annex A

Consistency

The test cases in this section ensure that the semantics of the CardInfo-file is correct and that the various definitions are consistent with each other.

Consistency of CardType-element

The following test cases aim at checking consistency aspects related to the CardType-element.

TestcaseExistence of BasisSpecification
Test IDC-CT-1
Description

This test case ensures that the BasisSpecification-element of an existing ProfilingInfo-element refers to a CardInfo-file in the card info repository.

If the BasisSpecification-element is not among the ObjectIdentifier-elements of the CardInfo-file in the card info repository, there will be a warning.

References[eCard-4]Annex A.3
TestcaseUniqueness of localized CardTypeName
Test IDC-CT-2
Description

This test case ensures that there is at most one localized CardTypeName for each language code.

If there are two or more CardTypeName-elements with the same xml:lang-attribute, there will be a warning.

References[eCard-4]Annex A.3
TestcaseCardInfoRepository reachable
Test IDC-CT-3
Description

This test case checks whether the specified CardInfoRepository, if specified, is reachable.

If the specified URI is not a URL or the location is not reachable, there will be a warning.

References[eCard-4]Annex A.3

Consistency of CardIdentification-element

The following test case aims at checking consistency aspects related to the CardIdentification-element.

TestcaseCard identification with APDUs only
Test IDC-CI-1
Description

The CharacteristicFeature-elements, which are used for the card type identification procedure contain a sequence of CardCall-elements, which are of type CardCallType. While the CardCallType allows to specify command and response pairs for APDUs (CommandAPDU / ResponseAPDU) or arbitrary API-calls (APICall / APIResponse), only the APDU-alternative is allowed within the card identification procedure.

If a CardCall-element within a CharacteristicFeature-element contains an APICall-element and a sequence of APIResponse-elements, there will be an error.

References[eCard-4]Annex A.4
TestcaseCard identification with admissible and recommended APDUs
Test IDC-CI-2
Description

This test case checks whether the APDUs used for the card type identification procedure use admissible and recommended commands.

The list of recommended INS-bytes and commands comprises:

  • B0 (READ BINARY)
  • B1 (READ BINARY)
  • B2 (READ RECORD)
  • B3 (READ RECORD)
  • CA (GET DATA)
  • CB (GET DATA)

The list of forbidden (non-admissible) INS-bytes and commands comprises:

  • 20 (VERIFY)
  • 21 (VERIFY)
  • 22 (MANAGE SECURITY ENVIRONMENT)
  • 24 (CHANGE REFERENCE DATA)
  • 2C (RESET RETRY COUNTER)

A forbidden INS-byte in a CharacteristicFeature-element will yield an error.

If the APDUs in a CharacteristicFeature-element use non-recommended commands a warning is issued.

References[eCard-4]Annex A.4
[eCard-4]Annex A.7

Consistency of CardCapabilities-element

The following test case aims at checking consistency aspects related to the CardCapabilities-element.

TestcaseInterface-URI
Test IDC-CC-1
Description

This test checks whether the Interface-elements specified in the CardCapabilities-section are among the supported URIs_

The list of currently supported Interface-URIs comprises:

  • urn:iso:std:iso-iec:7816:-3:tech:protocols:T-equals-0
  • urn:iso:std:iso-iec:7816:-3:tech:protocols:T-equals-1
  • urn:iso:std:iso-iec:10536:tech:protocols:T-equals-2
  • urn:iso:std:iso-iec:14443:-2:tech:protocols:Type-A
  • urn:iso:std:iso-iec:14443:-2:tech:protocols:Type-B

If there is an Interface-element, which is not among the values specified above, there will be an error.

Please contact Ecard.api(at)bsi.bund.de if there is an important URI missing.

References[eCard-4]Annex A.5

Consistency of ApplicationCapabilities-element

The following test cases aim at checking consistency aspects related to the ApplicationCapabilities-element.

TestcaseExistence of ImplicitlySelectedApplication
Test IDC-AC-1
Description

This test case ensures that the implicitly selected card application, if it is specified in an ImplicitlySelectedApplication-element, is among the set of application identifier elements of the specified card application.

If the ImplicitlySelectedApplication-element exists and the given application identifier is not among the set of ApplicationIdentifier-elements defined by the existing card application, an error will be issued.

References[eCard-4]Annex A.6
TestcaseCorrespondence of InterfaceProtocol and Interface
Test IDC-AC-2
Description

This test checks whether the InterfaceProtocol-elements of the card applications are among the Interface-elements specified in the CardCapabilities-section.

If there is an InterfaceProtocol-element, which is not among the Interface-elements supported by the card, there will be an error.

References[eCard-4]Annex A.5
[eCard-4]Annex A.6
TestcaseUniqueness of ApplicationIdentifier-elements
Test IDC-AC-3
Description

This test case ensures that the ApplicationIdentifier-elements within a CardInfo-file are unique.

If there are two or more card applications with the same ApplicationIdentifier, an error will be issued.

References[eCard-4]Annex A.6
TestcaseUniqueness of localized LocalApplicationName
Test IDC-AC-4
Description

This test case ensures that there is at most one localized LocalApplicationName for each language code.

If there are two or more LocalApplicationName-elements with the same xml:lang-attribute, there will be a warning.

References[eCard-4]Annex A.6
TestcaseUniqueness of CardApplicationServiceName-elements
Test IDC-AC-5
Description

This test case ensures that an explicitly specified CardApplicationServiceName within CardApplicationServiceInfo does not collide with the standardized card application service names and is unique within the present card application.

The set of standardized card application services and corresponding actions is given as follows:

  • CardApplicationServiceAccess
    • Initialize
    • Terminate
    • CardApplicationPath
  • ConnectionService
    • CardApplicationConnect
    • CardApplicationDisconnect
    • CardApplicationStartSession
    • CardApplicationEndSession
  • CardApplicationService
    • CardApplicationList
    • CardApplicationCreate
    • CardApplicationDelete
    • CardApplicationServiceList
    • CardApplicationServiceCreate
    • CardApplicationServiceLoad
    • CardApplicationServiceDelete
    • CardApplicationServiceDescribe
    • ExecuteAction
  • NamedDataService
    • DataSetList
    • DataSetCreate
    • DataSetSelect
    • DataSetDelete
    • DSIList
    • DSICreate
    • DSIDelete
    • DSIRead
    • DSIWrite
  • CryptographicService
    • Encipher
    • Decipher
    • GetRandom
    • Hash
    • Sign
    • VerifySignature
    • VerifyCertificate
  • DifferentialIdentityService
    • DIDList
    • DIDCreate
    • DIDGet
    • DIDUpdate
    • DIDDelete
    • DIDAuthenticate
  • AuthorizationService
    • ACLList
    • ACLModify

If the specified CardApplicationServiceName collides with a standardized card application name or if a CardApplicationServiceName appears more than once, an error will be issued.

References[eCard-4]Annex A.6
TestcaseServiceDescriptionURL reachable
Test IDC-AC-6
Description

This test case checks whether the ServiceDescriptionURL, if specified, is reachable.

If the specified URL is not reachable, there will be a warning.

References[eCard-4]Annex A.6
TestcaseUniqueness of AccessRules
Test IDC-AC-7
Description

This test checks whether the set of specified AccessRules is comprehensive and free of redundancy or contradictions.

If there is a standardized action (see above) for which there is no AccessRule-element, there will be warning.

If there is a standardized or loaded action for which there are two or more equal access rules there will be a warning.

If there is a standardized or loaded action for which there are two or more different access rules there will be an error.

References[eCard-4]Annex A.6
C-AC-5
TestcaseCardApplicationServciesName in AccessRule
Test IDC-AC-8
Description

This test checks whether the CardApplicationServiceName-elements inside some AccessRule are among the standardized or previously defined CardApplicationServiceName-elements.

If there is a CardApplicationServciesName-element, which is not among the standardized or previously defined elements, there will be an error.

References[eCard-4]Annex A.6
C-AC-5
TestcaseLoadedAction in AccessRule
Test IDC-AC-9
Description

This test checks whether the LoadedAction-elements inside some AccessRule are unique and do not collide with the standardized actions.

If a LoadedAction-element appears more than once, there will be an error.

If a LoadedAction-element collides with a standardized action (see above), there will be a warning.

References[eCard-4]Annex A.6
C-AC-5
TestcaseExistence of DIDName-elements in CardApplicationACL
Test IDC-AC-10
Description

This test case ensures that all DIDName-elements in some AccessRule within CardApplicationACL exist.

If there is a DIDName-element without a corresponding DifferentialIdentity-definition, an error will be issued.

References[eCard-4]Annex A.6
C-AC-16
C-AC-23
C-AC-26
TestcaseUniqueness of DIDName-elements
Test IDC-AC-11
Description

This test case ensures that the DIDName-identifiers are unique with respect to the scope of the Differential Identity (DID).

If there are two or more global Differential Identities (i.e. DIDScope=global) with the same DIDName in the CardInfo-file, an error will be issued.

If there are two or more local Differential Identities (i.e. DIDScope=local) with the same DIDName in the present card application, an error will be issued.

References[eCard-4]Annex A.6
TestcaseDIDProtocol-URI
Test IDC-AC-12
Description

This test checks whether the DIDProtocol-elements of the specified DifferentialIdentity-elements are among the supported URIs and appear again in the Protocol-attribute of the protocol-specific child-element of DIDMarker.

The list of supported protocols and DIDProtocol-URIs comprises:

  • urn:oid:1.3.162.15480.3.0.9 (PinCompare)
  • urn:oid:1.3.162.15480.3.0.12 (MutualAuthentication)
  • urn:oid:1.3.162.15480.3.0.14 (ExtendedAccessControl)
  • urn:oid:1.3.162.15480.3.0.15 (RSAAuthentication)
  • urn:oid:1.3.162.15480.3.0.25 (GenericCryptography)
  • urn:oid:0.4.0.127.0.7.2.2.2 (TerminalAuthentication)
  • urn:oid:0.4.0.127.0.7.2.2.3 (ChipAuthentication)
  • urn:oid:0.4.0.127.0.7.2.2.4 (PACE)
  • urn:oid:0.4.0.127.0.7.2.2.5 (RestrictedIdentification)

If there is a DIDProtocol-element, which is not among the values specified above, there will be an error.

In a similar manner there will be an error, if there is a mismatch between the DIDProtocol-element and the corresponding Protocol-attribute of the child element or the content of the DIDMarker-element.

Please contact Ecard.api(at)bsi.bund.de if there is an important URI missing.

References[eCard-4]Annex A.6
[eCard-7]
[EAC-2]
TestcaseExisting PinValue-element in PinCompareMarker
Test IDC-AC-13
Description

While the PinValue-element may be used for the creation of a PinCompare-Marker it should obviously never be specified in a CardInfo-file and hence an error is returned if this element is present.

References[eCard-4]Annex A.6
[eCard-7]Section 3.1
TestcaseConsistency of PIN-length-attributes in Pin Compare protocol
Test IDC-AC-14
Description

This test checks whether the different length-related attributes in the PasswordAttributes of the PinCompareMarker are consistent.

If the storedLength or the maxLength, if present, is smaller than minLength an error is returned.

References[eCard-4]Annex A.6
[eCard-6]Section 3.3.1
[eCard-7]Section 3.1
TestcaseExisting lastPasswordChange-element in PinCompareMarker
Test IDC-AC-15
Description

While the lastPasswordChange-element may be returned in DIDGetResponse it should not be specified in a CardInfo-file and hence an error is returned if this element is present.

References[eCard-4]Annex A.6
[eCard-7]Section 3.1
TestcaseExistence of DIDName-elements in StateTransition of Pin Compare protocol
Test IDC-AC-16
Description

This test case ensures that all DIDName-elements in some DIDAuthenticationState within StateTransition exist.

If there is a DIDName-element without a corresponding DifferentialIdentity-definition, an error will be issued.

References[eCard-4]Annex A.6
C-AC-10
TestcaseAlgorithm-URI in Generic Cryptography protocol
Test IDC-AC-17
Description

This test checks whether the Algorithm-element within AlgorithmIdentifier contains a supported URI.

The list of supported algorithms comprises:

  • Signature Algorithms
    • urn:oid:1.2.840.113549.1.1.1 (rsaEncryption, cf. RFC 3447)
    • urn:oid:1.2.840.113549.1.1.5 (sha1WithRSAEncryption, cf. RFC 3447)
    • urn:oid:1.2.840.113549.1.1.10 (RSASSA-PSS, cf. RFC 3447) in which case the Parameters/HashAlgorithm/Algorithm may be as follows:
      • urn:oid:urn:oid:1.3.14.3.2.26 (SHA-1, cf. RFC 3447)
      • urn:oid:urn:oid:2.16.840.1.101.3.4.2.1 (SHA-256, cf. RFC 5754)
      • urn:oid:urn:oid:2.16.840.1.101.3.4.2.2 (SHA-384, cf. RFC 5754)
      • urn:oid:urn:oid:2.16.840.1.101.3.4.2.3 (SHA-512, cf. RFC 5754)
      • urn:oid:urn:oid:2.16.840.1.101.3.4.2.4 (SHA-224, cf. RFC 5754)
    • urn:oid:1.2.840.113549.1.1.11 (sha256WithRSAEncryption, cf. RFC 3447)
    • urn:oid:1.2.840.113549.1.1.12 (sha384WithRSAEncryption, cf. RFC 3447)
    • urn:oid:1.2.840.113549.1.1.13 (sha512WithRSAEncryption, cf. RFC 3447)
    • urn:oid:1.2.840.113549.1.1.14 (sha224WithRSAEncryption, cf. RFC 5754)
    • urn:oid:1.3.36.3.3.1.2 (rsaSignatureWithRipemd160, cf. TTT-OID-Sig)
    • urn:oid:1.3.36.3.4.2.2.1 (sigS_ISO9796-2Withrsa_sha1, cf. TTT-OID-Sig)
    • urn:oid:1.3.36.3.4.2.2.2 (sigS_ISO9796-2Withrsa_ripemd160, cf. TTT-OID-Sig)
    • urn:oid:1.3.36.3.4.2.2.3 (sigS_ISO9796-2Withrsa_sha224, cf. TTT-OID-Sig)
    • urn:oid:1.3.36.3.4.2.2.4 (sigS_ISO9796-2Withrsa_sha256, cf. TTT-OID-Sig)
    • urn:oid:1.3.36.3.4.2.2.5 (sigS_ISO9796-2Withrsa_sha384, cf. TTT-OID-Sig)
    • urn:oid:1.3.36.3.4.2.2.6 (sigS_ISO9796-2Withrsa_sha512, cf. TTT-OID-Sig)
    • urn:oid:1.2.840.10040.4.3 (dsa-with-SHA1, cf. RFC 5480)
    • urn:oid:2.16.840.1.101.3.4.3.1 (dsa-with-SHA224, cf. RFC 5480)
    • urn:oid:2.16.840.1.101.3.4.3.2 (dsa-with-SHA256, cf. RFC 5480)
    • urn:oid:1.2.840.10045.4.1 (ecdsa-with-SHA1, cf. RFC 5480)
    • urn:oid:1.2.840.10045.4.3.1 (ecdsa-with-SHA224, cf. RFC 5480)
    • urn:oid:1.2.840.10045.4.3.2 (ecdsa-with-SHA256, cf. RFC 5480)
    • urn:oid:1.2.840.10045.4.3.3 (ecdsa-with-SHA384, cf. RFC 5480)
    • urn:oid:1.2.840.10045.4.3.4 (ecdsa-with-SHA512, cf. RFC 5480)
  • Encryption Algorithms
    • urn:oid:1.2.840.113549.1.1.1 (rsaEncryption, cf. RFC 3447)
    • urn:oid:1.2.840.113549.1.1.7 (RSAES-OAEP, cf. RFC 3447)
  • Hash Algorithms
    • urn:oid:urn:oid:1.3.14.3.2.26 (SHA-1, cf. RFC 3447)
    • urn:oid:urn:oid:2.16.840.1.101.3.4.2.1 (SHA-256, cf. RFC 5754)
    • urn:oid:urn:oid:2.16.840.1.101.3.4.2.2 (SHA-384, cf. RFC 5754)
    • urn:oid:urn:oid:2.16.840.1.101.3.4.2.3 (SHA-512, cf. RFC 5754)
    • urn:oid:urn:oid:2.16.840.1.101.3.4.2.4 (SHA-224, cf. RFC 5754)
    • urn:oid:urn:oid:1.3.36.3.2.1 (RIPEMD-160, cf. TTT-OID-Hash)
    • urn:oid:urn:oid:1.3.36.3.2.3 (RIPEMD-256, cf. TTT-OID-Hash)

If there is an Algorithm-element, which does not contain a URI specified above, there will be an error.

In a similar manner there will be a warning, if the string-based Algorithm-element corresponding to a supported URI does not contain the corresponding name specified above.

Please contact Ecard.api(at)bsi.bund.de if there is an important URI missing.

References[eCard-4]Annex A.6
[RFC3447]
[RFC5754]
[RFC5480]
[TTT-OID-Hash]
[TTT-OID-Sig]
TestcaseKey-material for the Generic Cryptography protocol
Test IDC-AC-18
Description

This test checks whether the CardInfo-file contains key material for the Generic Cryptography protocol.

If the SecretKeyValue-, PrivateKeyValue-, PublicKeyValue- or generateFlag-element is present there will be an error.

References[eCard-4]Annex A.6
[eCard-7]Section 3.5
TestcaseConsistency of supported operations in Generic Cryptography protocol
Test IDC-AC-19
Description

This test checks whether the SupportedOperations-element contains the following admissible values and otherwise yields an error:

  • Signature Algorithm:
    • Compute-signature
    • Verify-signature
    • Generate-key
    • Decipher
    • Internal-authenticate
  • Encryption Algorithm:
    • Encipher
    • Decipher
    • Generate-key
  • Hash Algorithm:
    • Hash
References[eCard-4]Annex A.6
[eCard-7]Section 3.5
C-AC-17
TestcaseSignatureGenerationInfo-element only for signature algorithms
Test IDC-AC-20
Description

This test makes sure that a SignatureGenerationInfo-element is only specified for a signature algorithm.

If there is a SignatureGenerationInfo-element for a non-signature algorithm there will be an error.

References[eCard-4]Annex A.6
[eCard-7]Section 3.5
C-AC-17
TestcaseHashGenerationInfo-element only for hash algorithms
Test IDC-AC-21
Description

This test makes sure that a HashGenerationInfo-element is only specified for a hash algorithm.

If there is a HashGenerationInfo-element for a non-hash algorithm there will be an error.

References[eCard-4]Annex A.6
[eCard-7]Section 3.5
C-AC-23
TestcaseUnnecessary elements for hash algorithms
Test IDC-AC-22
Description

This test makes sure that there are no unnecessary elements for hash algorithms.

If there is a CardAlgRef-, KeyInfo-, CertificateRef-, LegacyKeyName- or StateInfo-element for a hash algorithm, there will be an error.

References[eCard-4]Annex A.6
[eCard-7]Section 3.5
C-AC-17
TestcaseExistence of DIDName-elements in DIDACL
Test IDC-AC-23
Description

This test case ensures that all DIDName-elements in some AccessRule within DIDACL exist.

If there is a DIDName-element without a corresponding DifferentialIdentity-definition, an error will be issued.

References[eCard-4]Annex A.6
C-AC-10
C-AC-26
TestcaseUniqueness of DataSetName-elements
Test IDC-AC-24
Description

This test case ensures that the DataSetName-identifiers in a specific card application are unique.

If there are two or more data sets in a card application with the same DataSetName, an error will be issued.

References[eCard-4]Section 3.4
[eCard-4]Annex A.6
TestcaseUniqueness of LocalDataSetName
Test IDC-AC-25
Description

This test case ensures that there is at most one LocalDataSetName for each language code.

If there are two or more LocalDataSetName-elements with the same xml:lang-attribute, there will be a warning.

References[eCard-4]Annex A.6
TestcaseExistence of DIDName-elements in DataSetACL
Test IDC-AC-26
Description

This test case ensures that all DIDName-elements in some AccessRule within DataSetACL exist.

If there is a DIDName-element without a corresponding DifferentialIdentity-definition, an error will be issued.

References[eCard-4]Annex A.6
C-AC-10
C-AC-23
TestcaseUniqueness of DSIName-elements
Test IDC-AC-27
Description

This test case ensures that the DSIName-identifiers within a specific data set are unique.

If there are two or more data structures for interoperability (DSI) within a data set with the same DSIName, an error will be issued.

References[eCard-4]Section 3.4
[eCard-4]Annex A.6
TestcaseCorrectness of StateInfo-elements
Test IDC-AC-28
Description

This test case verifies the structural correctness of the StateInfo-element, which may appear in a PinComparMarker, PACEMarker or CryptoMarker. This includes the following checks:

  1. If the StateRecognition-element exists, this tests verifies that there is at least one operational state, which is reachable from a RecognizedState using appropriate StateTransition-elements.
  2. If there is no StateRecognition-element, but there is a State-element with StateClass-attribute equal to RecognitionNecessary, there will be an error.
  3. If there is a State-element with StateClass-attribute equal to RecognitionNecessary, which contains one or more StateTransition-elements, there will be an error.
  4. Finally this test verifies that all used UsageCounter and RetryCounter-elements are initialized by appearing in a State-element or a StateTransition-element, which contains an UpdateCounter-element with operation-attribute equal to set.
References[eCard-7]Section 3.1.1
TestcaseConsistency of PIN-length-attributes in PACE protocol
Test IDC-AC-29
Description

This test checks whether the different length-related attributes of the PACEMarker are consistent.

If both the minLength and maxLength elements are present and the maxLength is smaller than minLength, an error is returned.

References[eCard-7]Section 3.3.14
C-AC-14
TestcaseCorrectness of DIDStateQualifier-elements for EAC-protocol
Test IDC-AC-30
Description

This test checks whether the usage and content of the DIDStateQualifier-elements for the EAC-protocol are correct.

In order to check the correct usage of the DIDStateQualifier-element it is verified that the corresponding DID uses the Terminal Authentication protocol (urn:oid:0.4.0.127.0.7.2.2.2).

In order to check the correctness of the form, it is verified that DIDStateQualifier-element is formed according to one of the following alternatives:

  • Authenication Terminal: 7F4C12060904007F0007030102025305 followed by 5 bytes for the specific right (CHAT).
  • Signature Terminal: 7F4C12060904007F0007030102035301 followed by 1 byte for the specific right (CHAT).
References[eCard-7]Section 3.3.1
[eCard-7]Section 3.5.1
[eCard-7]Section 3.6.3
TestcaseCorrectness of DIDStateQualifier-elements for RSA Authentication-protocol
Test IDC-AC-31
Description

This test checks whether the content of the DIDStateQualifier-elements for the RSA Authentication protocol are as specified in the eGK-specification.

This check is applicable for DIDStateQualifier-elements, which corresponding DID uses the RSA Authentication protocol (urn:oid:1.3.162.15480.3.0.15).

For those DIDStateQualifier-elements it is checked that they are exactly seven (7) bytes long and have the following form:

  • D27600004000 followed by 1 byte for the specific right (CHAT).
References[eGK-2]Annex B
[eCard-7]Section 3.3.1
[eCard-7]Section 3.5.1
[eCard-7]Section 3.6.3
TestcaseProtection of sensitive key objects by Signature-element
Test IDC-S-1
Description

This test case ensures that all elements of KeyRefType (i.e. PinRef in PinCompareMarker, KeyRef in RSAAuthMarker, KeyRef in CryptoMarker and PasswordRef in PACEMarker), which contain a Protected-element, which is set to True, are protected by a Signature-element.

If there is a key object, which contains a Protected-element, which is set to True and is not protected by a Signature-element, there will be an error.

References[eCard-4]Annex A.7
TestcaseKeyInfo with child-elements different from X509Data
Test IDC-S-2
Description

This test case ensures that each Signature-element contains a KeyInfo-element, which only contains X509Data-elements.

If there is a Signature-element without a KeyInfo-element or the KeyInfo-element contains child elements different from X509Data, there will be an error.

References[eCard-4]Annex A.7

CardConformity

The test cases in this section ensure that the provided CardInfo-file is in fact conform to the provided card.

Conformity of the CardType-element

The following test cases aim at verifying that the specified CardType-element is conform to the provided card.

TestcaseConformity of ATR-element
Test IDCC-CI-1
Description

This test case checks whether the ATR-element returned by the card corresponds to one of the specified ATR-elements.

If the ATR returned by the card does not match any of the specified ATR-elements, there will be an error.

References[eCard-4]Annex A.4
TestcaseConformity of ATS-element
Test IDCC-CI-2
Description

This test case checks whether the ATS-element returned by the card corresponds to the specified ATS-element.

If the ATS returned by the card does match the specified ATS-element, there will be an error.

References[eCard-4]Annex A.4
TestcaseConformity of CharacteristicFeature-elements
Test IDCC-CI-3
Description

This test case checks whether the execution of all CardCall-elements in all CharacteristicFeature-elements yields the expected results.

If there is a CardCall, for which the transmission of the CommandAPDU yields some response, which is different from all specified ResponseAPDU-elements, there will be an error.

References[eCard-4]Annex A.4

Conformity of the CardCapabilities-element

The following test cases aim at verifying that the specified CardCapabilities-element is conform to the provided card.

TestcasePath to EF.DIR
Test IDCC-CC-1
Description

This test case checks whether the path to EF.DIR, if specified, is correct.

If the EF.DIR-element is present and the file is not accessible using READ BINARY, READ RECORD or GET DATA (as specified by the Card service data byte within the historical bytes) and the path specified in the Path-element, there will be an error.

References[eCard-4]Annex A.5
TestcasePath to EF.ATRorINFO
Test IDCC-CC-2
Description

This test case checks whether the path to EF.ATRorINFO, if specified, is correct.

If the EF.ATRorINFO-element is present and the file is not accessible using READ BINARY, READ RECORD or GET DATA (as specified by the Card service data byte within the historical bytes) and the path specified in the Path-element, there will be an error.

References[eCard-4]Annex A.5

Conformity of the ApplicationCapabilities-element

The following test cases aim at verifying that the specified ApplicationCapabilities-element is conform to the provided card.

TestcaseApplicationIdentifier correct
Test IDCC-AC-1
Description

This test case checks whether it is possible to select the card application specified by the ApplicationIdentifier-element.

For this purpose it is first checked, whether the application can be selected without an additional authentication step (i.e. the CardApplicationACL contains an AccessRule with CardApplicationServiceName=ConnectionService, ConnectionServiceAction=CardApplicationConnect and SecurityCondition/always=true). If this condition is not satisfied the test case is aborted with a warning that performing an authentication protocol for selecting the application is currently not supported.

If it is possible to select the card application without additional authentication steps the following APDU is sent to the card:

  • CLA=00
  • INS=A4 -- SELECT
  • P1=04 -- by DF name (AID)
  • P2=0C -- first occurance, no response data
  • Data=aid -- Application Identifier

If the response APDU is different from '9000', an error is returned.

References[eCard-4]Annex A.6
[ISO7816-4]Section 7.1.1
TestcasePinCompareMarker/PinRef/KeyRef correct
Test IDCC-AC-2
Description

This test case checks whether the key reference of a PIN is correct by sending a VERIFY-command without data field.

If it is possible to enter the PIN without additional authentication steps (i.e. the DIDACL contains an AccessRule with CardApplicationServiceName=DifferentialIdentityService, DifferentialIdentityServiceAction=DIDAuthenticate and SecurityCondition/always=true) the following APDU is sent to the card:

  • CLA=00
  • INS=20 -- VERIFY
  • P1=00 -- according to ISO/IEC 7816-4
  • P2=KeyRef -- PIN reference
  • Data = absent

The response APDU '6A88' indicates that the reference data has not been found and hence an error is returned.

If the response APDU is different from '9000', '63Cx' and '6A88' there will be a warning, which indicates that there is a PIN, which is not operational and that the result of the following status check should be carefully considered.

If the relevant access rule indicates that any authentication steps are necessary before the PIN can be entered, there will be a warning which indicates that this functionality is currently not supported.

References[eCard-4]Annex A.6
[ISO7816-4]Section 7.5.6
TestcaseRecognition of PIN-state possible
Test IDCC-AC-3
Description

This test case checks whether it is possible to recognize the state of the PIN using the specified StateRecognition-elements.

For this purpose the sequence of specified CardCall-elements is sent to the card and the response is compared with the specified value.

If the response produced by the card matches an expected response, the state seems to be recognized and a corresponding message will be returned, which indicates that the card is in the specified state. In this case, the possible transitions are returned for informational purposes.

If a second state seems to be recognized there will be an error, which indicates that the specified state recognition procedures are ambiguous.

If there is a StateInfo- and StateRecognition-element and no state is recognized after sending all the specified CardCall-elements to the card, there will be an error, which indicates that the state recognition procedure failed.

References[eCard-4]Annex A.6
[ISO7816-4]Section 7.5.6
TestcasePIN-entry possible as specified
Test IDCC-AC-4
Description

This test case checks whether the PIN can be successfully entered as specified.

For this purpose it is first checked, whether the PIN is in an operational state (the VERIFY-APDU in CC-AC-2 returned '9000' or '63Cx') and the specified padding mechanism is equal to bcd, ascii-numeric, half-nibble-bcd or iso9564-1. If this is not the case, this test case will be aborted with a warning which indicates that the PIN is not operational or requires a padding method, which is currently not supported.

Next it is checked that the PIN can be entered without additional authentication steps, which would require other authentication protocols. If other authentication protocols are required, the test case is aborted with a corresponding warning.

Otherwise all required PINs are captured and sent to the card using the following APDU:

  • CLA=00
  • INS=20 -- VERIFY
  • P1=00 -- according to ISO/IEC 7816-4
  • P2=KeyRef -- PIN reference
  • Data = PIN, padded as specified

The response APDU '9000' indicates that the PIN has been entered correctly.

All other responses indicate some error.

References[eCard-4]Annex A.6
[ISO7816-4]Section 7.5.6
C-AC-2
TestcaseSignature generation possible as specified in SignatureGenerationInfo
Test IDCC-AC-5
Description

This test case is performed for all private signature keys and checks whether the signature generation is possible as specified in the corresponding SignatureGenerationInfo.

This means that the AlgorithmIdentifier/Algorithm-element must contain the URI of a signature algorithm and the SupportedOperations-element must include the Compute-signature-flag (cf. test cases C-AC-17 and C-AC-19).

For this purpose it is first checked, whether the signing operation is possible without authentication protocols different from the PinCompare-protocol. If there are other authentication protocols required, the test case will abort with a corresponding warning, which indicates that currently only the PinCompare-protocol is supported.

If only PIN-based authentication steps are required, the necessary PINs are captured and sent to the card as described in test case CC-AC-4.

Now the sequence of APDUs specified by the SignatureGenerationInfo-element is sent to the card and it is verified if it is possible to generate a signature with the specified sequence of APDUs. If the response APDUs are different from '9000' an error is returned.

The different tokens within the SignatureGenerationInfo-element correspond to the following APDUs:

  • MSE_RESTORE
    • CLA=00
    • INS=22 (MSE)
    • P1=F3 (RESTORE)
    • P2=B6 (DST
    • Lc= absent for Nc=0
    • Data is absent
    • Le= absent for Ne=0
  • MSE_HASH
    • CLA=00
    • INS=22 (MSE)
    • P1=41 (SET)
    • P2=AA (HT)
    • Lc= absent for Nc=0
    • Data equals 80|length(HashAlgRef)|HashAlgRef
    • Le= absent for Ne=0
  • PSO_HASH
    • CLA=00
    • INS=2A (PSO)
    • P1=90 (Hash)
    • P2=A0
    • Lc= absent for Nc=0
    • Data equals 90|length(Hashvalue)|Hashvalue
    • Le= absent for Ne=0
  • MSE_Key
    • CLA=00
    • INS=22 (MSE)
    • P1=41 (SET)
    • P2=B6 (DST)
    • Lc= absent for Nc=0
    • Data equals 84|length(KeyRef)|KeyRef
    • Le= absent for Ne=0
  • MSE_DS
    • CLA=00
    • INS=22 (MSE)
    • P1=41 (SET)
    • P2=B6 (DST)
    • Lc= absent for Nc=0
    • Data equals 80|length(CardAlgRef)|CardAlgRef
    • Le= absent for Ne=0
  • MSE_KEY_DS
    • CLA=00
    • INS=22 (MSE)
    • P1=41 (SET)
    • P2=B6 (DST)
    • Lc= absent for Nc=0
    • Data equals 84|length(KeyRef)|KeyRef|80|length(CardAlgRef)|CardAlgRef
    • Le= absent for Ne=0
  • PSO_CDS
    • CLA=00
    • INS=2A (PSO)
    • P1=9E (CDS)
    • P2=9A (Data to be signed)
    • Lc= absent for Nc=0
    • Data is absent (if PSO_HASH is used) or equals Data to be signed
    • Le= absent for Ne=0
  • INT_AUTH
    • CLA=00
    • INS=88 (Internal Authenticate)
    • P1=00 (no information given)
    • P2=00 (no information given)
    • Lc=length of Data to be signed
    • Data equals Data to be signed
    • Le= absent for Ne=0
References[eCard-4]Annex A.6
[ISO7816-4]7.5.11
[ISO7816-4]7.5.2
[ISO7816-8]11.7
[ISO7816-8]11.8
C-AC-17
C-AC-19
C-AC-4
TestcaseDecryption possible
Test IDCC-AC-6
Description

This test case is performed for all private encryption keys and checks whether the decryption is possible using the specified key reference and algorithm identifier.

This means that the AlgorithmIdentifier/Algorithm-element must contain the URI of an encryption algorithm and the SupportedOperations-element must include the Decipher-flag (cf. test cases C-AC-17 and C-AC-19).

For this purpose it is first checked, whether the decryption operation is possible without authentication protocols different from the PinCompare-protocol. If there are other authentication protocols required, the test case will abort with a corresponding warning, which indicates that currently only the PinCompare-protocol is supported.

If only PIN-based authentication steps are required, the necessary PINs are captured and sent to the card as described in test case CC-AC-4.

Now the required sequence of APDUs as explained below is sent to the card and it is verified if the decryption is possible without error. If the response APDUs are different from '9000' an error is returned.

  • MSE_SET
    • CLA=00
    • INS=22 (MSE)
    • P1=41 (SET)
    • P2=B8 (DECIPHER)
    • Lc= absent for Nc=0
    • Data equals 84|length(KeyRef)|KeyRef|80|length(CardAlgRef)|CardAlgRef
    • Le= absent for Ne=0
  • PSO_DECIPHER
    • CLA=00
    • INS=2A (PSO)
    • P1=80 (plain value)
    • P2=86 (data is ciphertext with padding indicator)
    • Lc= absent for Nc=0
    • Data equals PaddingIndicator|Ciphertext, where PaddingIndicator='00'
    • Le=number of expected octets
References[eCard-4]Annex A.6
[ISO7816-4]7.5.11
[ISO7816-8]11.13
C-AC-17
C-AC-19
C-AC-4
TestcaseHashing on card as specified in HashGenerationInfo possible
Test IDCC-AC-7
Description

This test case is performed for each DID, which is meant to be used for hashing on the card.

This means that HashGenerationInfo-element is equal to CompletelyOnCard or LastRoundOnCard, the AlgorithmIdentifier/Algorithm-element must contain the URI of a hash algorithm and the SupportedOperations-element must include the Hash-flag (cf. test cases C-AC-17 and C-AC-19).

If these prerequisites are fulfilled, the following APDUs are used if the hashing is to be performed CompletelyOnCard:

  • MSE_HASH
    • CLA=00
    • INS=22 (MSE)
    • P1=41 (SET)
    • P2=AA (HT)
    • Lc= absent for Nc=0
    • Data equals 80|length(HashAlgRef)|HashAlgRef
    • Le= absent for Ne=0
  • PSO_HASH (first or only)
    • CLA=00
    • INS=2A (PSO)
    • P1=90 (Hash)
    • P2=A0
    • Lc= absent for Nc=0
    • Data equals 90|00|80|length(Data)|Data for first or only data block
    • Le = absent to indicate that an intermediate or hash value is only stored on the card or present to indicate that hash value is to be returned.
  • PSO_HASH (further)
    • CLA=00
    • INS=2A (PSO)
    • P1=90 (Hash)
    • P2=A0
    • Lc= absent for Nc=0
    • 80|length(Data)|Data for further data blocks if required
    • Le = absent to indicate that an intermediate or hash value is only stored on the card or present to indicate that hash value is to be returned.

If these prerequisites mentioned above are fulfilled and the hashing is to be performed with LastRoundOnCard, the IntermediateHashValue and Counter are calculated in software before the following APDUs are send to the card:

  • MSE_HASH
    • CLA=00
    • INS=22 (MSE)
    • P1=01 (SET)
    • P2=AA (HT)
    • Lc= absent for Nc=0
    • Data equals 80|length(HashAlgRef)|HashAlgRef
    • Le= absent for Ne=0
  • PSO_HASH (last only)
    • CLA=00
    • INS=2A (PSO)
    • P1=90 (Hash)
    • P2=A0
    • Lc= absent for Nc=0
    • 90|length(IntermediateHashValue|Counter)|IntermediateHashValue|Counter|80|length(Data)|Data
    • Le= absent to indicate that hash value is only stored on the card or present to indicate that the hash value is to be returned.
References[eCard-4]Annex A.6
[ISO7816-4]7.5.11
[ISO7816-8]11.8
C-AC-17
C-AC-19
C-AC-4
TestcaseAccessing Data Sets possible
Test IDCC-AC-8
Description

This test case is performed for each Data Set and checks that the corresponding files can be selected with the file identifier specified in the DataSetInfo/DataSetPath/efIdOrPath-element and accessed using READ BINARY, READ RECORD or GET DATA (as specified by the Card service data byte within the historical bytes).

For this purpose the DataSetACL-element within a DataSetInfo is checked to ensure that the Data Set can be accessed without authentication or with PIN-based authentication only. This means that there is an AccessRule, in which the SecurityCondition indicates that the access is always possible or that only a sequence of authentication steps using DIDs featuring the PinCompare-protocol is required. If there are other authentication protocols required, the test case will abort with a corresponding warning, which indicates that currently only the PinCompare-protocol is supported.

If only PIN-based authentication steps are required, the necessary PINs are captured and sent to the card as described in test case CC-AC-4.

References[eCard-4]Annex A.6
[ISO7816-4]7.1.1
[ISO7816-4]7.2.3
[ISO7816-4]7.3.3
[ISO7816-4]7.4.2
CC-AC-4

CardRecognition

TestcaseUnique card type recognition with respect to repository
Test IDCR-1
Description

This test case checks whether it is possible to uniquely recognize the card type given the existing CardInfo-files in the repository and the additional CardInfo-file, which is currently tested.

If the card type recognition procedure will not be unique anymore, there will be an error which contains an explanation why the unique card type recognition would not be possible and what should be changed in the CardInfo-file to fix this problem.

References[eCard-4]Annex A.3
TestcaseCitizen client is able to recognize card type
Test IDCR-2
Description

If there have not been any other errors reported for the currently tested CardInfo-file, this test case finally checks whether the citizen client is able to recognize the type of the currently tested card.

For this purpose the test application will determine all available card application paths using the CardApplicationPath-function and push the CardInfo-file to the citizen client using the AddCardInfoFiles-function. If this has been successfully performed, the test application will ask the tester to insert the card and determine the available card application paths again using the CardApplicationPath-function a second time.

The currently tested card should appear in the set of returned card application paths. If this is not the case, an error will be returned.

In any case the CardInfo-file will removed from the citizen client using the DeleteCardInfoFiles-function.

References[eCard-4]Annex A.3

References

LabelDescription
[CardInfo.xsd]BSI: eCard-API-Framework - Schema Documents - CardInfo.xsd, in https://www.bsi.bund.de/cae/servlet/contentblob/477252/publicationFile/63224/wsdl_xsd_2010-04-30.zip
[EAC-2.05]BSI: Advanced Security Mechanisms for Machine Readable Travel Documents - Extended Access Control (EAC), Password Authenticated Connection Establishment (PACE), and Restricted Identification (RI), Technical Guideline of the BSI no. 03110, Version 2.05, via https://www.bsi.bund.de/cae/servlet/contentblob/532066/publicationFile/62746/TR-03110_v205_pdf.pdf
[eCard-4]BSI: eCard-API-Framework - Part 4 - ISO24727-3-Interface, Technical Guideline of the BSI no. 03112-4, via https://www.bsi.bund.de/cae/servlet/contentblob/477242/publicationFile/61080/api1_teil4_pdf.pdf
[eCard-6]BSI: eCard-API-Framework - Part 6 - IFD-Interface, Technical Guideline of the BSI no. 03112-6, via https://www.bsi.bund.de/cae/servlet/contentblob/477248/publicationFile/61082/api1_teil6_pdf.pdf
[eCard-7]BSI: eCard-API-Framework - Part 7 - Protocols, Technical Guideline of the BSI no. 03112-7, via https://www.bsi.bund.de/cae/servlet/contentblob/477244/publicationFile/61083/api1_teil7_pdf.pdf
[eGK-2]gematik: Spezifikation der elektronischen Gesundheitskarte, Teil 2: Grundlegende Applikationen, Version: 2.2.0, Stand: 25.03.2008 via http://www.gematik.de/cms/media/dokumente/release_0_5_3/release_0_5_3_egk/gematik_eGK_Spezifikation_Teil2_V2_2_0.pdf
[ISO7816-4]ISO/IEC 7816-4: Identification cards - Integrated circuit cards - Part 4: Organization, security and commands for interchange, International Standard, 2005
[ISO7816-8]ISO/IEC 7816-8: Identification cards - Integrated circuit cards - Part 8: Security related interindustry commands, International Standard, 2004
[ISO9564-1]ISO/IEC 9564-1: Banking – Personal Identification Number management and security – Part 1: PIN protection principles and techniques, International Standard, 1996
[TTT-OID-Hash]TeleTrusT: OID-Liste {1 3 36 3 2} (hash algorithm), via http://www.teletrust.de/fileadmin/docs/projekte/oid/OID-Liste_1_3_36_3_2.pdf
[TTT-OID-Sig]TeleTrusT: OID-Liste {1 3 36 3 3} (signature algorithm), via http://www.teletrust.de/fileadmin/docs/projekte/oid/OID-Liste_1_3_36_3_3.pdf
[RFC3279]W. Polk, R. Housley, L. Bassham: Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3279, via http://www.ietf.org/rfc/rfc3279.txt
[RFC3447]J. Jonsson, B. Kaliski: Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1, RFC 3447, via http://www.ietf.org/rfc/rfc3447.txt
[RFC5480]S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk: Elliptic Curve Cryptography Subject Public Key Information, RFC 5480, via http://www.ietf.org/rfc/rfc5480.txt
[RFC5754]S. Turner: Using SHA2 Algorithms with Cryptographic Message Syntax, RFC 5754, via http://www.ietf.org/rfc/rfc5754.txt