MOBILE E-SIGNATURE SOLUTION IMPLEMENTATION

Check our service models!

Technology of NETLOCK│SIGN, based on innovative server-side key storage, can be flexibly embedded in enterprise IT systems and is capable of managing securely the key and certificate data of a large number of users. It makes the user able to authenticate documents with legal effect on any device, anywhere, and anytime. During the daily use, this solution replaces both the complex smart card-based key storage and the related card readers and software products, thus it can fully support mobility and use of mobile devices.

PRODUCT INFORMATON

The general product information of NETLOCK│SIGN can be downloaded here.

ACCEPTED IN THE EUROPEAN UNION!

highest level qualified digital signature

The NETLOCK | SIGN solution is capable of generating the highest level of qualified electronic signatures and stamps and qualified timestamps accepted in the European Union, so that the documents it certifies are uniformly accepted in all Member States and are equivalent to handwritten signatures.

EXCELLENT SECURITY

user private keys are cryptographic
generated and stored in secure hardware

For high security and reliability, user keys are generated and stored in Hardware Security Module (HSM) only in a way that can be used/activated by the certificate owner. The NETLOCK|SIGN solution can support simple one-factor or multiple strong two-factor user authentication. The latter is required by some functions and enforced at system level.

Add-on software component

When installing and using the NETLOCK|SIGN CSP optional add-on software component, the signing end users’ NETLOCK|SIGN signing certificate is added to the local Windows certificate store and becomes available in any local signing application (such as Adobe Reader, MOKKA signing application, etc.) like traditional smart card signatures the ability to sign with NETLOCK|SIGN certification.

IMPLEMENTATION OPTIONS

Depending on enterprise client requirements, NETLOCK│SIGN Enterprise is available in three different service and deployment models. Each model is distinguished from the others by the followings:

Public cloud

(Public service)

Hybrid cloud

(Hash-based hybrid service)

Private cloud

(Implemented at the client)

Key storage location

In cloud (in HSM-based secure environment) In cloud (in HSM-based secure environment) At client side

Location of signature

In cloud In cloud & client side At client side

Visibility of a document

Service Provider can have access Service Provider cannot have access Service Provider cannot have access

Service model

SaaS service SaaS service with a communication software module installed at the client (hibrid module or CSP) Supply of software with software upgrade and support


Support for qualified signatures

Supported Supported NOT SUPPORTED (advanced signatures based on qualified certificate at most)

PUBLIC CLOUD

null
Public electronic signature service
DETAILS

HYBRID CLOUD

null
Hash-based electronic signature service
DETAILS

PRIVATE CLOUD

null
Electronic signature service implemented at the client
DETAILS

INTEGRATION OPPORTUNITIES

REST API

Whether it’s an online trust service (Software as a Service – SaaS) or a dedicated solution installed at the client, all functions of the system are available through the REST API interface, which includes:

1

Felhasználó-életciklusmenedzsment (létrehozás, szerkesztés, jogosultsági beállítások, törlés, aktiválás/inaktiválás, aktiválókód-csere)

2

User Life Cycle Management (creation, editing, authorization settings, deletion, activation/deactivation, activation code change)

3

The electronic signature, sealing, time stamping, and signature verification functions

4

OAUTH2.0-based user authentication and user authentication features traced back to qualified signatures

PUBLIC CLOUD

Public electronic signature service

The high-level system architecture of the public cloud-based NETLOCK│SIGN service is shown below embedded in a typical, integrated enterprise IT environment.

NetlockSign_public_implementation_1200_V2_en_figure
  • In this case, the electronic signatures service is available as a public Software-as-a-Service (SaaS) service via the Internet without the need for building an own signing infrastructure.

  • Key generation, key storage, and electronic signing all take place on the secure central HSM devices of the trust service provider and can be activated only by the end user.

  • Before signing, the client’s IT system must send the file to be signed to the NETLOCK SIGN secure signature environment that can be presented to the signing end user before signing, if necessary.

  • In this case, the electronic signature service provider can have access to the contents of the document to be signed but they will be stored only during the period of signature, and then will be automatically deleted.

  • If long-term authentic archiving of the document is required, the authenticated files can be automatically transferred to the qualified archiving services of the trust service provider.

  • On the customer side, this solution does not require local signature infrastructure, so this solution can be introduced in the fastest and most cost-effective way.

  • NETLOCK│SIGN ENTERPRISE clients can also turn on the Public Signing Portal (PSS), which provides electronic signature service functionality without enterprise integration.

ADDITIONAL IMPLEMENTATION OPTIONS

Depending on your enterprise customer requirements, NETLOCK│SIGN Enterprise is available in two additional implementation models.

HYBRID CLOUD

Hash-based hybrid electronic signature service

The high-level system architecture of the hash-based NETLOCK│SIGN electronic signature service is shown below embedded in a typical, integrated enterprise IT environment.

NetlockSign_hybrid_implementation_figure_en
  • In this case, the electronic signatures service is available as a public Software-as-a-Service (SaaS) service via the Internet, however by means of a communication signature support module installed at the client.

  • Signature requests along with the files to be signed will be sent to this SIGNASSIST signature support module on the site of the customer by the related IT systems. After generating a hash, the document to be signed does not leave the customer’s site – just like during qualified time stamping services –, only the DTBS hash, generated from the document, as well as optionally ID of the signing end user will be forwarded to the electronic signature services by the signature support module.

  • DTBS hash will be signed in the central NETLOCK SIGN signing environment of the trust service provider by the private key of the signing end user that is stored centrally and can be activated solely by the given user. After signing, the generated signature – and the time stamp, if necessary – will be built into the file to be signed and returned to the calling system by the signature support module installed on the site of the customer.

  • Key generation, key storage, and first phase of electronic signing all take place on the secure central HSM devices of the trust service provider and can be activated only by the end user.

  • In this case, the electronic signature service provider cannot have access to the contents of the document to be signed, thus this option is recommended for clients where the document to be signed shall not leave the site of the company for legal or security reasons but the localization of the entire signing infrastructure is not justified or not economical.

  • The Hybrid Cloud Architecture also includes the implementation of the optional plug-in software component NETLOCK|SIGN CSP. Using this add-on software, the hybrid model can perform impression-based operation directly on the client side without using the server-side SIGNASSIST CryptoServer. When you use NETLOCK|SIGN CSP, the signing end-user NETLOCK|SIGN signing certificate is added to the local Windows certificate store, making NETLOCK|SIGN available to any locally installed or used signing application (such as Adobe Reader, MOKKA, etc.). In this case, the NETLOCK|SIGN CSP only sends an imprint of the document to be signed to the NETLOCK|SIGN signature service.

ADDITIONAL IMPLEMENTATION OPTIONS

Depending on your enterprise customer requirements, NETLOCK│SIGN Enterprise is available in two additional implementation models.

PRIVATE CLOUD

Electronic signature service implemented at the client

If the client wants to use both the signing keys and the entire signing infrastructure locally, we recommend choosing a NETLOCK SIGN solution installed at the client. The high-level system architecture of this solution is shown below embedded in a typical, integrated enterprise IT environment.

NetlockSign_private_implementation_figure
  • In this case, the customer purchases the license of the locally installable NETLOCK SIGN electronic signature software or the complete full package product with their annual support and software upgrade, which include also the qualified time stamping services.

  • In addition to the necessary server hardware, this solution requires the acquisition of HSM module(s) or the use of already existing network-based NetHSM modules.

  • When using a solution, installed at the client, the entire signing environment will be installed locally and the signing keys of all the end users will be generated in the HSM modules located on the site of the client and can be used only there. External network connection (outside the IT environment of the client) is required only for time stamping services as well as certificate applications and certificate status queries.

  • Use of non-fault-tolerant and redundant NETLOCK SIGN solutions is also supported. In this model, the trust service provider neither can have access to the contents of the documents to be signed nor are the signing keys under its control. This solution is recommended for large enterprises and clients with serious IT security competencies where – for legal and/or security reasons – both key storage and signing should take place locally, within the site of the company, under their own operation.

  • Qualified electronic signatures and stamps based on a qualified certificate cannot be created in this model because, under current EU legislation, the private signing keys for such certificates can only be stored by a qualified trust service provider. This way, the private cloud model provides the creation of advanced signatures based on up to qualified certificates.

ADDITIONAL IMPLEMENTATION OPTIONS

Depending on your enterprise customer requirements, NETLOCK│SIGN Enterprise is available in two additional implementation models.