Before a NetKey/ IDKey from a set of new cards is assigned to a person or a system, the integrity of the card can be ensured by checking its NullPIN status. Use of the card combined with the assignment of a personal PIN by the person or system destroys this protective seal and ties the card to the PIN owner (knowledge).

From this time onwards, NetKey/ IDKey allows so-called two-factor authorization based on possession and knowledge.

Advantages:

TeleSec NetKey/ IDKeys can be stockpiled in advance without having to know precise future needs. Personalization takes place after a NetKey/ IDKey has been handed out.

The fact that the PIN letter which is usually required for plastic cards can be dispensed with makes it possible to optimize procedures in terms of finance, administration and human resources thanks to:

Simplified inventory control,

Postage cost savings,

Savings on expensive special paper forms for PIN letters,

Savings on administrative effort required to ensure the correct assignment of PIN letter to card,

Savings on expense of enveloping PIN letters,

Savings on postage for time-staggered dispatch of PIN letter.

The end user chooses their own password (PIN) which is easy to remember and consistent with the way they think. (Such a password can consist of any character from the entire ASCII character set with a recommended password length of up to 64 characters. The use of PIN keypads of secure card readers, for example, may make it necessary to use only numbers 0 to 9.)

The appropriate certification service is dictated, as a rule, by the context of use. Various certificate issuers offer their services worldwide on the Internet.

Large companies and organizations often have their own public key Infrastructures (PKI) for issuing and managing advanced certificates. This means that a participant is registered in accordance with the rules of the respective provider. Also, certification service providers (CSPs) who offer so-called qualified certificates have begun operating in various countries in the last few years. The country in question stipulates specific requirements regarding registration quality before a qualified certificate can be issued. Similarly, the quality of Secure Signature Creation Devices (SSCDs) is also specified.

The question of whether or not TeleSec NetKey is suitable as a SSCD has to be agreed in each individual case with the competent CSP. A list of possible certification services can be found in Appendix 1.

In this case the owner of the NetKey/ IDKey must undergo a registration process carried out by a recognized certification service. When doing so, proof of actual identity must be furnished in accordance with the relevant requirements of the certification service, e.g., based on a personal presentation and submission of an ID document.

The certification service only issues a certificate after it has approved the submitted proof of identity. The certification service acts as a so-called “third authority”. This means that the issued certificate is no longer merely an alleged identity but a verifiable identity.

Certification services also usually provide checking options in the form of standardized directory and revocation services.

In the simplest case, the owner of a NetKey/ IDKey can issue himself a certificate. This is then a self-signed certificate. Strictly speaking, the owner therefore only claims that he has a specific identity and possesses a specific key.

From a technical viewpoint, such certificates can be used for all purposes whereby the certificate is accepted as being legitimate. Identity checking in such cases usually takes place in advance, e.g., by phone or in a face-to-face meeting when there is an agreement to collaborate on this basis.

The identity of a person is usually verified when needed by presenting an identity document. Visible identity attributes such as a photo, eye color or distinctive features such as scars are compared in order to do this.

If such an ID document is lost, the person may have to apply for a new ID, for example by presenting a family register to the registrar. Before a certificate is issued, the certification authority may, by checking a submitted ID document, check the identity of the applicant.

The quality of this checking forms the basis of the quality of the certificate.

An e-mail address can, for instance, only be used as an identity attribute if steps are taken to ensure that the associated e-mail account is under the applicant's control. This check can be performed by sending and replying to a confirmation e-mail.

The key generator in the TeleSec trust center does not store any keys, keys are transferred to the smartcard via encrypted lines in T Systems' security-certified trust center. This completely excludes the possibility of any duplicates, the secret key is therefore located exclusively in the TCOS chip.

After a NetKey/ IDKey has been produced, the secret keys can only be used for cryptographic operations inside the TCOS chip. The use of secret keys is protected by a PIN, i.e., only authorized users can use secret keys.

A key pair is usually generated in software in the user's browser, the public part is incorporated in the certificate request and this is signed with the secret part in order to provide proof of the authenticity of the public key. The secret key is then stored in the computer and password protected (usually in a PKCS #12 container).

In contrast, TeleSec NetKey/ IDKey introduces key pairs that were created in T-Systems' trust center in a highly secure key generator. This key generator can only export these keys to appropriate TCOS chips. This export is cryptographically secure enough to prevent any possibility of keys being intercepted. There can therefore be no key copies.

Middleware integrates NetKey/ IDKey into the operating system platform in a way that ensures that the public key material of the TCOS smartcard is used when an application requests a key pair.

A plug-in for the TCOS card manager is provided for test purposes; this can be used to generate self-signed test certificates that can be written to the card. To do this, the OpenSSL open-source library must also be installed. The plug-in only supports NetKey 3.0 and IDKey TCOS 3 smartcards.

These certificates do not use the key pairs that are pre-personalized on TCOS 3 smartcards during production. There is no trustworthy root or the possibility of certificate checking (LDAP/OCSP) for these certificates.

This is why these self-generated certificates can only be used in some applications to a limited extent. We always recommend using premium certificates from a corresponding CA with a trustworthy root and directory services in order to check the trustworthiness and validity of certificates.

TCOS Card Module for MS BaseCSP The card module provides TCOS card functionality in all applications through MS CryptoAPI. This means e-mail security as well as signature and encryption/decryption in Outlook are basic components or the signature from Microsoft Word 2003 onwards. If the web page operator makes provision for this, smartcard login and hence security for both user and operator can be used. Windows logon can be realized in various ways depending whether or not your system is integrated in a Windows domain.

PKCS#11 The PKCS#11 SDK offers the possibility of integrating enhanced data security easily. For example, in Lotus Notes or Mozilla for e-mail signature and encryption/decryption for greater security and trust in the case of general e-mail correspondence.

Further applications include the evidian SSO client, cryptovision (ultimaco and pgp are being planned).

Under Microsoft Windows, there is a so-called BaseCSP in order to integrate hardware tokens. The interface for integrating a card module is described. There is such a card module for NetKey/ IDKey and it is available for Windows 7 onwards from Windowsupdate.com.

This means that as soon as a NetKey/ IDKey is detected, the TCOS module is automatically loaded as required. After installing the card module, NetKey/ IDKey is treated as a PKCS#12 container. The user can present the public key from NetKey/ IDKey in order to request a certificate.

The cryptographic middleware in Windows negotiates everything else with the TCOS chip. The usual password for using the secret key from a PKCS#12 container is replaced by requesting the NetKey/ IDKey PIN. A PKCS#11 library which can be installed as part of a software setup is available for other operating systems such as Linux.

For embedded systems, NetKey/ IDKey can be integrated using specially developed drivers. The smartcard operating system is fully documented and provides an ISO 7816-4 compliant interface.

In life and at work, individuals are assigned several roles that involve different tasks and authorizations as a rule. In order to carry out duties and make use of authorizations, proof that they have been lawfully assigned is required in every case. To do this, a person is given, e.g., for each role, a separate certificate or there is a role and rights management system which administers authorizations on the basis of a higher-level certificate.

This means that a person must either furnish proof that they have the right secret key for the relevant certificate or prove to the role and rights management system that they are the right person for the relevant role.

Once again, here the person may be challenged to use the correct secret key for the higher-level certificate.

Because NetKey/ IDKey only proves that its owner is allowed to use a role with the relevant certificate, the certificate for the role must be installed or be accessible on all computer systems on which the person is to exercise their role. The smartcard – the NetKey/ IDKey – is only required in order to authorize actions in conjunction with the certificate.

Because of NetKey/ IDKey's two-factor security, it must be carried around for mobile use and therefore remains under its owner's control.

This is the job of identity management systems. This is where the aggregation of attributes is managed and assigned to specific identities. Identity attributes can be assigned when a person or system is not present as a rule.

Systems and applications that offer usage based on the presentation of attributes receive these directly from the identity management service. An authorized owner uses their NetKey/ IDKey to provide evidence that they are authorized to use an attribute.

The actual identity of a NetKey/ IDKey owner can be accessed by the choice of attributes during registration in order to issue a certificate.

After presenting its identification data to the certification service, a pseudonymous attribute is entered as the certificate owner. In the event of a dispute, the actual identity behind the pseudonym can be traced.

The basic requirements governing disclosure are a result of the certification service's basic principles and, possibly, legal requirements.