Journal of Network and Computer Applications 56 (2015) 101–114

Contents lists available at ScienceDirect

Journal of Network and Computer Applications

journal homepage: www.elsevier.com/locate/jnca

A novel federated strong mobile signature service—The Finnish case

Esa Kerttula n,1
Prof-Tel Oy Ltd, Långhagintie 32, 02480 Kirkkonummi, Finland

art ic l e i nf o a b s t r a c t

Article history: This paper describes the legal framework, architecture with standards and signature services of the new
Received 14 July 2014 public Finnish federated strong mobile signature scheme. Mobile signatures are used, for example, for
Received in revised form user identification and authentication, the message authentication, non-repudiation of transactions and
26 March 2015
verifying the information integrity. The service is based on mobile PKI and on the federation of security
Accepted 3 June 2015
Available online 4 July 2015
assertions using ETSI MSS standards. The service provider needs an agreement only with one operator.
Then all services in the Circle of Trust may request authentication and digital signing from user even if a
Keywords: service provider has made an agreement with other competing operator than the home operator of the
Signature service user. The signature service platform is extremely secure using strong two-factor and two-channel model.
Mobile identity
All personal security credentials are stored and the crypto-operations run in the mobile operator's
Strong identification
tamper-proof secure element, UICC. The Finnish mobile signature service fulfils the strong identification
Mobile PKI
Federated signature in the Finnish ‘Identification’ Act. The service platform offers potentially to millions of Finnish citizens
Circle of Trust and the participating Finnish businesses convenient to use and trusted signature services on various
service channels for applications hosted on the premises or in the cloud. Signature services can be used
also abroad where SMS services are provided and where user's operator has a roaming agreement.
& 2015 Elsevier Ltd. All rights reserved.

1. Introduction
Mobile voice and data communication is a ubiquitous part of
modern life. User device technology and network performance
continue to advance in accelerating steps from ‘dumb’ phones to
smartphones and tablets, and from 3 G to 4 G, and in other
wireless networks. The drivers demand for access to open net-
works and services in the information society, demanding the
importance of reliable user identification and authentication, non-
repudiation of transactions and confidence in and integrity of the
information and services.
Critical services, such as banking, healthcare, e-government
services, online voting, etc., need high-level digital signature services.
1.1. Current authentication schemes
The methods for proving the identity of individual remote
customers and/or devices and secure transmission of data are
mostly based on passwords, one-time passwords (OTP), challenge/
response protocols, transaction signing, user certificates, biometrics
and device fingerprints (Fabian, 2009; VIP Access for Mobile, 2010;
OATH Reference Architecture, 2007).
RSA SecurID, PIN/TAN2 schemes and SMS-OTP (e.g. mobile
TANs), are widely used examples of OTP. Smart cards, EMV
payment or debit cards containing a separate CAP application
(CHIP Authentication Program) in conjunction with unconnected
reader, USB key fobs and software tokens, are other examples. The
password-based authentication is the oldest and still most com-
monly used method for user authentication. Protection through
single password cannot be considered secure enough, e.g. for
online banking. That is why there exists a second security layer,
or PIN/TAN. In Finland the widely used PIN/TAN service is called
‘Tupas’, or Bank ID (TUPAS Identification Service, 2010).
Certificate-based authentication uses public-key encryption
techniques, supported by a public-key infrastructure (PKI) for
key and certificate management. Digital certificates are issued by
a certification authority (CA). They bind the user's identity to her
public key. In a typical certificate-based authentication protocol,
client uses her private key to sign a challenge from the service, and
the service verifies the signature using client's certificate (or public
key). Finnish Citizen ID card is an example of certificate-based
authentication scheme (www.fineid.fi).

n
Tel.: þ 358 45 6700 447.
E-mail address: esa.kerttula@proftel.fi
1
Esa Kerttula, owner of Prof-Tel Oy Ltd, the telecommunications consulting
2
company, http://www.proftel.fi. Professor (until May 1st, 2012) in Telematics in PIN (Personal Identification Number), TAN (Transaction Authentication Num-
Lappeenranta University of Technology, Finland. Senior Member of IEEE. ber), used e.g. in net-banking.

http://dx.doi.org/10.1016/j.jnca.2015.06.007
1084-8045/& 2015 Elsevier Ltd. All rights reserved.
102 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114
1.2. Digital identity
Digital identity has often been defined as the set of data or
attributes of a natural or legal person, or non-human subject (or an
entity), required in order to gain access to a particular service or
resource in the real or virtual world. However, definitions of digital
identity may vary according to different regulatory contexts.
The cost of capturing and associating a digital identity to a real
identity is inversely proportional to the risk of providing the service.
The registration process fundamentally defines the risk. The strength,
or robustness, of this registration process ultimately describes the
model of trust within which the identity exists, and the position it
occupies within that model (GSMA Europe Response to European
Commission consultation on eSignatures and eIdentification, 2011).
1.2.1. Federated digital identity
Identity models fall into two main groups: federated and
integrated. A federated model involves a small number of autho-
rities issuing identity credentials that are shared by interest
groups, or organizations and users. These allow businesses to re-
use credentials issued for other company offline and online
environments. Current examples of internationally recognized
federated Digital ID solutions include Liberty Alliance, SAML2.0
and OpenID (GSMA Europe Response to European Commission
consultation on eSignatures and eIdentification, 2011).
Finnish mobile signature scheme is PKI-based federated identity
system with trusted, reliable and high-quality registration process
and ensuring low risk for relying services. By the digital signature in a
certificate, the mobile operator (CA) guarantees that it has checked,
according to its policies, that the subject identity mentioned inside
the certificate is indeed the owner of the public key that is inside the
same certificate, and that this public key owner also is in possession
of the corresponding private key. The signature in the certificate can
be verified by anybody, by using the issuing CA's public key.
Integrated models provide a system that places the application
provider at the center of the commercial model. So the business
drivers become the focal point of the model and authentication, as
such, is an enabler.
By sharing certificates organizations are able to reduce cost,
increase integrity and offer a faster and more integrated service
experience to the user.
1.3. Mobile identity and signing tool
Mobile phone is an ideal device to provide authentications and
digital signatures in everybody's daily life. Mobile phone is personal,
raising the feeling about ‘my digital, or my mobile identity’, and as a
‘signing-tool’, the feeling of electronic equivalent of a pen.
Mobile operators are trusted parties in the society having more
than twenty years of experience of the efficient and cost-effective
SIM card, or UICC3, logistics in GSM/UMTS networks.
Finnish mobile signature service is developed and implemen-
ted together by TeliaSonera Finland, Elisa and DNA, in close co-
operation with FiCom4 under the commercial concept of Finnish
Mobile ID. The service to the general public was launched in June
2011 (www.mobiilivarmenne.fi/en/index.html).
GSMA Mobile Identity case study paper (Finnish Mobile ID – A
Lesson in Interoperability, 2013) describes and discusses the inter-
operability, economics and success factors of the Finnish Mobile ID.
3
UICC (Universal Integrated Circuit Card), a smart card, containing SIM/USIM
application in GSM/UMTS terminals.
4
Finnish Federation of Communications and Informatics.
1.4. Content of the paper
Section 2 presents the legal framework and Section 3 the
architecture with federation of signature services of the Finnish
mobile signature service. Section 4 describes the signature services
and the value-added services of the scheme. Section 5 discusses
the service security and trust. In Section 6 versatility of the Finnish
mobile signature scheme to mass-usage is studied. Section 7
presents the discussion and Section 8 the conclusions.
2. Legal framework
The legal framework of Finnish mobile signatures is laid down
in the Finnish Act on Strong Electronic Identification and Electro-
nic Signatures (Act on Strong Electronic Identification and Digital
Signatures, 2009), or the ‘Identification’ Act, and on the Personal
Data Act (Personal Data Act, 1999).
2.1. ‘Identification’ Act
The ‘Identification’ Act (617/2009) is first of such kind in the
world, in that the Act lays provisions not only for electronic
signature but also for strong identification.
The digital signature part of ‘Identification’ Act replaces the
previous Finnish Act on Digital Signatures (14/2003) implement-
ing EU Directive 1999/93/EC on a Community framework for
electronic signatures (European Union Directive, 1999).5
The ‘Identification’ Act lays down provisions on strong electro-
nic identification and electronic signatures, as well as on offering
these services to service providers using them and to the general
public. The ‘Identification’ Act entered into force on 1st Sept. 2009.
2.1.1. Electronic signatures
The Directive 1999/93/EC distinguishes between ‘electronic
signatures’ and ‘advanced electronic signatures’ which may be
created with signature-creation devices depending on their char-
acteristics. Electronic signature means data in electronic form which
is attached to or logically associated with other electronic data and
which serves as a method of identification.
An advanced electronic signature is defined as an electronic
signature that meets the following requirements: (a) it is uniquely
linked to the signatory, (b) it is capable of identifying the signatory,
(c) it is created using means that the signatory can maintain under
her sole control, and (d) it is linked to the data to which it relates in
such a manner that any subsequent change of the data is detectable.
Signature-creation devices may be used in the execution of legal
transactions. If a signature is required for a legal transaction, an
advanced electronic signature based on a qualified certificate and
created with a secure-signature-creation device (SSCD) will satisfy this
requirement. Such a qualified signature meets the same legal require-
ments than hand-written signature, and provides the non-repudiation.
The ‘Identification’ Act does not uniquely exclude the possibi-
lity that legal effect is entered into force also with other than
advanced electronic signature created with qualified certificate.
A digital signature is an electronic signature generated using a
cryptographic transformation. Digital signatures are used in user
and message authentication, in non-repudiation (signing), in
transaction verification and in information integrity protection.
5
In ‘Digital Single Market’ pillar of the Europe 2020 Strategy, European
Commission has proposed new legal comprehensive EU cross-border and cross-
sector framework for secure, trustworthy and easy-to-use electronic transactions
that encompasses eID and trust services (eIDAS). Within that framework, a new
Regulation (EU) 910/2014 will repeal with effect from 1 July 2016 the Directive
1999/93/EC (ec.europa.eu/digital-agenda/en/trust-services-and-eid).
 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114 103

2.1.2. Types of certificates
The Citizen Certificate is issued by Finnish State to Finnish
citizens. The certificate is issued solely, in accordance with the
law, by the Population Register Centre (PRC) (www.fineid.fi).
Citizen Certificate complies with the EU Directive on electronic
signatures and with the ‘Identification’ Act. The Citizen Certificate
comprises two certificates, one being an authentication and
encryption certificate and the other a signature certificate. Signa-
ture certificate is a qualified certificate.
A certificate is a qualified certificate if the certificate and the CA
meet the high quality and other requirements of EC directive (see
above the qualified signature). A qualified certificate includes
liability to CA for damage caused by CA. CA may indicate limita-
tions in a qualified certificate on the use of that certificate (e.g. the
value of legal transaction).
At present, PRC is the only CA who issues qualified certificates
in Finland.
PRC creates an electronic identity for Finnish citizens when
providing them with a Personal Identity Code (HETU in Finnish). The
electronic identity is activated as a Citizen Certificate when the citizen
receives an identity card issued by the police, for instance. Then the
Citizen Certificate is embedded in the chip of identity card (ID card).
Mobile certificate issued by mobile operator to the general
public in Finnish mobile signature service is not a qualified
certificate. So, the digital signatures created with mobile certificate
are not qualified signatures.
Mobile operators have not applied for the status of qualified CA.
Technically the mobile certificate meets all the requirements of
qualified certificate, as well as the signature-creation device
(UICC), the requirements of SSCD laid down in the EU Directive
1999/93/EC.
For provisions of the mobile certificate, the common Certificate
Policy (CP) prepared by FiCom is laid down. For provisions on
issuing the certificate, each operator has its own Certificate
Practice Statement (CPS). These can be found on the web-page of
Finnish Communications Regulatory Authority (www.ficora.fi/en/
etusivu.html).
2.2. Personal Data Act
On issuing the identification devices, on maintaining the
service and on performing the identification event, the identifica-
tion service provider may use the personal data required. The
Personal Data Act (523/1999) (Personal Data Act, 1999) lays down
the provisions. On the same grounds, the certification service
provider may collect and process personal data for issuing and
maintaining certificates.
Also, the Personal Data Act includes the provisions on request-
ing the HETU for reliably verifying the identity of an applicant, on
processing and maintaining the HETU in registers and on including
the identity code in identification devices or certificates.
Personal Data Act defines a notion of consent. Consent means
any voluntary, detailed and conscious expression of will, whereby
the data subject approves the processing of her personal data.
Finnish mobile signature scheme supports consent signature
service (Section 4).
3. Mobile signature services architecture
3.1. Service components and roles
An overview of the Finnish federated mobile signature services
architecture is shown in Fig. 1 (Kerttula, 2009). The user has many
roles. One of the roles is based on the mobile subscription and
being the USIM card holder. In this role the user has tight

End-user roles Service Providers

• Card holder • Finance services
• User • Transport services
• Customer • Public services
(responsible payer) • Commerce
• Enterprice services
Operator • Gaming
Signature • Other IdP-services
service • Etc

ETSI 102-204
MSSP

Other operators

MSSP

On-line CA
registration 1)
Operator CA
• Certificate on-line • CP and CPS
registration (Tupas) • Revocation
• Electronic ID compilation service
• Tupas + Population Register
• Operator CRM + Centre
Directory
• Bank CRM +
• PIS PIS
CRL • HETU
• SATU

1) Check when registering certificate, SATU request

MSSP (Mobile Signature Service Provider ), CA ( Certification Authority ), CP (Certificate Policy), CPS ( Certification
Practice Statement ), CRL (Certificate Revocation List ), IdP ( Identity Service Provider ), CRM (Customer Relationship
Management ), PIS (Population Information System ), HETU ( Personal Identity Code ), SATU (Electronic Client Identifier )

Fig. 1. System components of Finnish mobile signature service, only the basic Internet-based service channels are shown.
104 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114
relationship with mobile operator, which guarantees high trust
level for the user and the service provider.
Operators act as a Certification Authority (CA) and take care of
the RA (Registration Authority) functions in their local offices. The
RAs authenticate and register user, issue USIM cards and provide
help desk service. The CA issues mobile certificates, manage
certificate suspension and revocation and the repository. For
certificate and signature validity checks, Online Certificate Status
Protocol (OCSP) may be used.
At the moment there are three mobile signature service
providers (MSSP), or mobile operators, in the Finnish scheme.
The architecture, however, is open for new type of signature
service providers, and also for service providers (SP).
The operators having full mobile PKI capability may federate
security assertions to those parties not having a PKI service by
using ETSI MSS Standards.
3.1.1. Circle of trust
Home MSSP (HMSSP) and SPs contracted with MSSP form the
Circle of Trust (CoT). Circle of Trust is a cooperative framework, an
agreement between the three main Finnish operators, under
which the operators accept digital identities created by each other,
and allow those identities roam on their network and make use of
agreements that each individual operator has with third party SPs.
Circle of Trust based on ETSI standards and standardized Web-
service interfaces is unique feature which differentiates Finnish
mobile signature scheme from many other similar schemes. The
trust agreement establishes an open four-corner business model.
3.1.2. Personal electronic identifiers
The Population Register Centre (PRC) creates the Personal Elec-
tronic Identifier (SATU in Finnish) to Finnish citizens when providing
them with the HETU. In the legislation (Act 617/2009) all authorized
strong ID providers, including mobile operators, can issue electronic
ID (eID) credentials with the SATU. This enables registration for the
Mobile ID to take place in the operators' stores.
SATU is used for electronic user identification in secure online
transactions. SATU is activated when a person receives a mobile
certificate. Mobile certificate is a digital identity, which contains,
among other permanent information, a citizen's first name, last
name and SATU.
3.1.3. Mobile certificate issuance
For the signature security the process of customer registration
is the key issue. This is the point at which trust is laid down
between the registering party, the authenticating party and the
customer. The registration process should be applied uniformly,
rigorously and without compromise by mobile operators.
Under the ‘Identification’ Act (617/2009) it is possible for
private sector businesses with the relevant level of security and
authorization to also act as issuers of strong identification tokens
and services.
The ‘Identification’ Act requires that in registration process the initial
identification shall be done in person, assuring the highest quality level
in identification procedure. An exception of this rule is that if the
identification service providers have entered into a mutual agreement
on ways to rely on each other in performing the initial identification.
The ‘Identification’ Act allows for the issuing of new eID
credentials based on other previous strong eID credentials. This
makes it possible to issue Mobile ID over the Internet to customers
already in possession of a Bank ID.
After a successful registration process, the mobile certificate
will be transferred and located in the certificate repository. In
addition, some other information from mobile operator and bank's
CRM6 systems, as well as from PIS7, may be checked when
deciding the issuance and compiling the mobile certificate (Fig. 1).
3.2. Two-factor, two-channel model
Finnish mobile signature service is based on two-factor and
two-channel model. Two-factor means that each user has own
tamper-proof UICC and personal secure PINs, or SPINs. Two-
channel scheme means that the service channel, for example that
for net-banking (e.g. Internet), is separated from that used for
signatures (out-of-band).
In a general case, the service is used on PC or laptop, and the
user authentication/content signing happens separately on mobile
handset (two-terminal model).
Authentication/signing, and service, can also be provided on
the same mobile terminal, e.g. smart-phone or radio capable
laptop with UICC (one-terminal model). The terminal shall support
SIM Application Toolkit (SAT) capability. Not all terminal config-
urations, however, support SAT.
For authentication/signing channel the encrypted SMS is used.
3.2.1. Strong crypto algorithms
In the Finnish system authentication and digital signing is
based on RSA algorithm, with 1024 or 2048-bit key lengths, and
activated by personal SPINs. Separate SPIN codes are used inde-
pendently for authentication and for signing. For digest the SHA-1
or SHA-256/512 function is used.
RSA keys can be generated on-board in which case the USIM
card logistics is simpler and more secure.
Mobile signature is produced by the tamper-proof WPKI client,
a SAT application in the UICC. RSA and other crypto functions
(3DES, message digests) are pre-programmed in the UICC memory
by the card manufacturer.
3.2.2. Broad scope of service channels
Finnish mobile signature service is suitable to many kinds of
service channels, not just to those which can be accessed by
laptops or mobile devices. The concept is appropriate for applica-
tions requiring user's permission to proceed with completion of a
transaction initiated by
 open www-service (e.g. net-shop)
 closed www-service (e.g. net-bank)
 mobile Internet service
 mobile application
 SMS service
 a voice-call
 interactive voice response service
 face-to-face service
 TV channel, or
 some other electronic channel
3.3. Federation of signature services
3.3.1. ETSI architecture
ETSI TR 102 203 standard (ETSI TR 102 203, 2003) defines
business and functional requirements for mobile signature. ETSI TS
102 204 (2003) defines the standardized Web Service interface for
the mobile signature and user's mobile authentication. ETSI TR 102
206 (2003) defines the security framework of mobile signature
and ETSI TS 102 207 (ETSI TS 102 207, 2003) the standardized
interface for mobile signature roaming between mobile networks.
6
CRM (Customer Relationship Management).
7
PIS (Population Information System).
 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114
STANDARD
SIGN REQUEST
Mobile Device 1 mSigREQ-OP1 [mSigREQ-STD]
Mobile Device 2 Mobile Signature &
Mobile Device ...n mSigRESP-OP1 Service-1 STANDARD
SIGN RESPONSE
Mobile Operator 1 [mSigRESP-STD]
Mobile Device 1 mSigREQ-OP2
Mobile Device 2 Mobile Signature
Service-2 Application
Mobile Device ...n mSigRESP-OP2
Mobile Operator 2
Mobile Device 1 mSigREQ-OPn
Mobile Signature
Mobile Device 2
Service-n
Mobile Device ...n mSigRESP-OPn
Mobile Operator ...n
Fig. 2. Mobile signature service.
Fig. 2 shows the general principle of mobile signature service (ETSI
TS 102 204, 2003). MSSP is an intermediary between users and SP/APs
that provides and implements a mobile signature Web Service.
Standard protocol messages in Fig. 2 are XML-encoded, the
syntax and semantics of which are defined by W3C XML Schema
(Part1, Part2) (XML Schema, 2004). Syntax and semantics of
protocol messages of few additional mobile signature services are
defined in Finnish internal FiCom XML Schema (FiCom
Implementation Provisions for ETSI MSS Standards, 2012). The
WSDL v1.1 (WDSL 1.1, 2001) is used to describe the mobile signature
Web Service. Mobile signature messages in Fig. 2 are wrapped in
SOAP v1.2 (SOAP 1.2, 2003) envelopes in HTTP message body. SAML
v2.0 (SAML v2.0, 2005) form of assertions is used for describing and
exchanging the person identity and attribute information. SAML
assertions are signed using XML Signature (XML Signature, 2008).
The mobile signature is encoded according to PKCS#7 or PKCS#1
standard (PKCS#7, 1993; PKCS#1, 2002).
3.3.2. Signature request
ETSI MSS standards define the mobile signature request in which
application provider (AP) may request user to sign electronically
some text content with mobile phone, by sending the user's home
operator the signature request message. The content to be signed
may, for example, be authentication challenge related to strong user
identification or authentication or order ratification in e-commerce
or confirmation of user profile modification, by using the advanced
electronic signature defined in the ‘Identification’ Act. Or, the
content to be signed may be whichever content requiring strong
electronic user authentication and/or non-repudiated signature.
The service provider does not require direct interface with the
user's home operator (HMSSP). It is enough if the service provider
has an agreement and technical interface allowing signature
requests defined in ETSI TS 102 204 standard with some operator
in the CoT. ETSI standard TS 102 207 defines routing of signature
request to MSSP (mobile signature roaming).
Fig. 3 shows one possible configuration of two MSSPs
(Technical Service Description – Operators' Mobile Certificate
Service, 2010). In this case, MSSP1 operates in addition to HMSSP
role also to the Acquiring Entity (AE) role. AE offers Web Service
interface to AP. MSSP2 may also have own separate AE service.
The different phases in signature request flow in Fig. 3 are
explained below.
User has opened, or is opening, a session in AP service by using
whichever service channel (e.g. browser channel of her laptop, mobile
browser channel, or voice-call channel) (phase 1). At the beginning or
during the session there arises a need for strong identification of the
user or for strong authentication of some property of the user, or
request the digital signature from the user. AP has an agreement with
the service provider's operator and technical interface to send
105
Fig. 3. Signature request flow.
signature requests. AP acquires through service channel the user's
mobile phone number, forms the content to be signed and sends
these together to AE in the message in form defined by ETSI TS 102
204 standard. In value-added service part of the message, AP may
request HMSSP to send additional information related to user identity.
AE verifies that the signature service and value-added service
elements requested by AP correspond to the Service agreement
(phase 2). By using the user's mobile phone and the Finnish
number portability management service (Numpac, not shown in
Fig. 3), AE inquires the user's HMSSP and sends the signature
request further to the HMSSP according to the protocol defined by
ETSI TS 102 207 standard. HMSSP may be administered by the
same MSSP (user 1) or other MSSP (user 2) than the AE.
HMSSP then verifies that the signature service and the value-
added service elements requested by AP are allowed by the user
(phase 3). HMSSP sends signature request to the user’s mobile
phone. AP's identifier shown to user has been agreed separately
between the AP and that AE in the Circle of Trust and registered on
partner profiles of all HMSSPs.
After signing the content requested by AP, HMSSP fetches from
CA's repository the certificate corresponding to users signing key
(phase 4). Signature and the corresponding certificate are com-
posed into digital signature message according to the PKC#7
standard. HMSSP processes the value-added service elements
requested by AP and encloses the responses of value-added service
elements with the digital signature message to AP (e.g. additional
information associated to the user identity).
HMSSP then validates the signature, or checks the validity
period of the user certificate and validity of digital signature
(phase 5). AE sends valid digital signature further to AP.
After processing the transaction, AP may send, if desired,
through AE to HMSSP the receipt message about the successful
transaction (phase 6). HMSSP sends confirmation about the
reception of receipt message to AE which sends that to AP.
3.3.3. Signature messaging modes
ETSI TS 102 204 standard describes three messaging modes:
synchronous, asynchronous client–server and asynchronous ser-
ver–server. Finnish system supports asynchronous client–server
and synchronous modes.
The asynchronous client–server mode is recommended in
which mode mobile signature consists of the following messages
(Technical Service Description – Operators' Mobile Certificate
Service, 2010; FiCom Implementation Provisions for ETSI MSS
Standards, 2012):
 signature request (MSS_SignatureReq)
 status inquiry (MSS_StatusReq),
 the status response (MSS_StatusResp)
 the optional receipt request (MSS_ReceiptReq), and
 the response (MSS_ReceiptResp).
106 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114
Fig. 4. Asynchronous signature messaging mode.
The transaction consists of several consecutive HTTP sessions
which are always opened from the AP side (Fig. 4). The MSSP
network is shown as one MSSP because, from AP point of view, the
whole technical system behind AE is transparent.
The different phases in the signature messaging in Fig. 4 are
explained below.
User opens the session to AP's server (phase 1). A need to log in or
signing an electronic agreement arises. User inputs her mobile phone
number and spam prevention code (Section 4) into AP's server.
AP shows to user a guide on the service channel (phase 2). The
guide directs user's attention to watch the signature channel
(mobile phone). On the guide user is told the event ID of the
signature event.
AP sends signature request (MSS_SignatureReq) to AE (phase
3). AP has integrated AE's Web Service interface. On value-added
part of the request AP may request HMSSP to deliver additional
information referred to user's identity.
After receiving the signature request and after generating the
MSSP event ID for the request (phase 4), AE returns event ID to AP.
On response message (MSS_SignatureResp) AE informs that trans-
action still is incomplete.
AE verifies that the signature service requested by AP and the
value-added service elements fulfils the requirements of Service
agreement (phase 5). AE processes the signature request and
directs that to user's HMSSP. HMSSP checks the spam prevention
code of the user and verifies that the signature service requested
by AP and the value-added elements are allowed by the user.
HMSSP sends signature request to the user's mobile phone.
User verifies that the event ID shown on mobile phone during
the introduction of transaction is the same than the event ID
shown on service channel (phase 6). After that the user signs the
transaction by inputting the SPIN requested. As a result, the digital
signature of the user is generated, which is sent to HMSSP.
From the digital signature, HMSSP compiles the signature mes-
sage according to PKC#7 standard, which is composed as part of the
signature response (MSS_StatusResp) (phase 7). HMSSP processes
the value-added elements requested by AP and encloses the
responses of the value-added elements with the digital signature
message to AP (e.g. additional information related to user identity).
After sending the signature request, AP inquires at regular
intervals about the status of signature response (MSS_StatusReq)
(phase 8).
HMSSP validates the digital signature (phase 9). AE informs AP
of the status of signature request in the status response (MSS_Sta-
tusResp). When the signature is ready, it is sent to AP as a part of
status response.
AP processes the received signature response (phase 10). AP
connects the user identified in digital signature and the user in the
AP's own user database. The user is now authenticated. When AP
is using another service channel, e.g. the self-updating web site,
the AP may now modify the content of web site in such a way that
user's browser is directed to the content requiring the user
authentication.
If so desired, AP may send user a receipt about the successful
transaction (MSS_ReceiptReq) (phase 11).
AP's receipt message is sent to user same way as the signature
request, but as a plain, non-encrypted SMS (phase 12).
The confirmation about delivering the receipt message
(MSS_ReceiptResp) is sent to AP (phase 13).
The asynchronous signature messaging mode is flexible com-
pared with synchronous mode. AP shall not to tie up the process (or
its thread) that sent the signature request in waiting for the signature
response. Instead, the process is free to perform other tasks and
check periodically whether the signature response is ready.
3.4. Based on international standards
Table 1 shows the main standards used in the Finnish mobile
signature service. The standards cover USIM, UICC and crypto
module, SAT, secure binary SMS messaging, ETSI mobile signature,
certificates and CRL's.
The signature service in applicable parts meets the European
Union e-Signature standards in the whole process with procedures
of registering the users, issuing certificates, requirements for
certification authorities (CA), signature formats and signature
creation and verification, as well as certificate policies (CP) and
certification practice statements (CPS).
In addition, guidelines for SSCD, signature format and CSP
implementation, policy and practice from ETSI, CEN and IETF8,
and the FiCom MSS application guideline (FiCom Implementation
Provisions for ETSI MSS Standards, 2012), are applied.
4. Security services provided
The security services provided in Finnish mobile signature ser-
vices platform are grouped into (Technical Service Description –
Operators' Mobile Certificate Service, 2010; FiCom Implementation
Provisions for ETSI MSS Standards, 2012)
 signature services, and
 value-added signature services
4.1. Signature services
The functionality of the signature services offered to service
providers and users is based on signature profiles. Signature
8
ETSI (European Telecommunications Standards Institute), CEN (European
Committee for Standardization), IETF (Internet Engineering Task Force).
 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114
Table 1
Main standards in Finnish strong mobile signature scheme (ETSI TR 102 203, 2003; ETSI TS 102 204, 2003; ETSI TR 102 206, 2003; ETSI TS 102 207, 2003; XML Schema, 2004;
WDSL 1.1, 2001; SOAP 1.2, 2003; SAML v2.0, 2005; XML Signature, 2008; 3GPP TS 11.14 v8.18.0, 2007; 3GPP TS 31.111 v9.2.0, 2010; 3GPP TS 43.019 v5.6.0, 2003; GSMA-SAS,
2008; 3GPP TS 03.38; UCS-2; PKCS#7, 1993; PKCS#1, 2002; PKCS#10, 2000; JavaCard 2.2; RFC 5652, 2009; ETSI TS 102 225, 2003; 3GPP TS 23.040, 2010; 3GPP TS 23.048,
2005; X509v3, 2005; RFC 5280, 2008; RFC 2560, 1999; RFC 3647, 2003).
UICC/USIM, SAT (USIM-ME) UICC, crypto module SMS
3GPP TS 11.14 RSA 1024, 2048 ETSI TS 102 225
3GPP TS 31.111 SHA-1/SHA-256/512 3GPP TS 23.040
3GPP TS 43.019 PKCS#1 3GPP TS 23.048
GSMA-SAS PKCS#7 3DES
3GPP TS 03.38 JavaCard 2.2.x
UCS-2, UTF-8 RFC 5652
services, allowing user authentication and non-repudiation (sign-
ing) in different kinds of legal transactions, are
 anonymous authentication service
 authentication service
 operator authentication service
 hash signature
 clear text signature
 consent
4.1.1. Anonymous authentication
Anonymous authentication service is intended for situations,
where some characteristics of a natural person using the mobile
certificate may be transmitted to service provider without reveal-
ing the user's identity. The service provider may by this way, for
example, find out nothing more but the information about age of
the user. This service, however, allows transmitting the informa-
tion related to person's authentication by using value-added
PersonIdentity-service (see Item 4.2.4).
Fig. 5 shows the user experience of anonymous authentication
(Technical Service Description – Operators' Mobile Certificate
Service, 2010). The service provider (AP) sends anonymous sig-
nature request to user's mobile phone (first screen). AP shall send
to user on the service channel the same event ID as shown on the
first screen, if possible (two-terminal mode).
AP's unique identifier shown to the user has been agreed
separately between AP and HMSSP. The second screen shows the
information about her to be transmitted to the AP. The content
depends on the parameters the AP has requested in PersonIdentity-
service. The third screen is always the same, requesting to input the
person's authentication SPIN for confirmation of the authentication.
The fourth screen is optional receipt message sent by AP about the
success or failure of transaction.
4.1.2. Authentication service
Authentication service is intended for authentication of a
natural person using mobile certificate. Service provider sends
authentication request to user's mobile phone. User authenticates
herself by entering her personal SPIN. AP may use the authentica-
tion service in two ways as follows:
 As a basic service where the authentication request is sent
without the value-added service, PersonIdentity. Information
identifying the user stored in data content of certificate is
returned in response message (the official name and SATU).
This case is suitable for those APs who are able to authenticate
their customer by using SATU and who do not require any
additional information about the user.
107
MSS Certificate, CRL, status CA, CP, CPS
ETSI TR 102 203 X.509v3 RFC 3647
ETSI TS 102 204 RFC 5280 UTF-8
ETSI TR 102 206 RFC 2560
ETSI TS 102 207 PKCS #10
SOAP 1.2
WDSL 1.1
XML Schema P1,P2
XML Signature
SAML v2.0
 Authentication request calls PersonIdentity-service. In this
case, also other information in addition to the certificate data
content is received in the response.
Fig. 6 shows user experience of authentication service (Technical
Service Description – Operators' Mobile Certificate Service, 2010).
The screens are same with same explanations as in anonymous
authentication (Fig. 5) except the second screen, where the person’s
identity information is shown. The content depends on which
parameters the AP has requested in the PersonIdentity-service.
4.1.3. Operator Authentication service
Operator Authentication service is used only by the operators
in the CoT. Authentication service uses authentication key in the
UICC. Operator may offer in the Web channel an authentication
service where, for example, the AP interface uses PIN/TAN-based
Finnish ‘Tupas’. Each AP joining the Authentication service may
have its own identifier.
Operator offers AP its own interface to signature service,
different from what is defined in the ETSI standards. The operator
Authentication service may be implemented according to ‘Tupas’
standards, or by using SAML federation.
In ‘Tupas’-type service the user is directed from her own Web
site to the Operator Authentication service offered by HMSSP. In the
Operator Authentication service, the user gives her mobile phone
number and the spam prevention code. After that the operator's
proxy service sends authentication request to CoT by adding AP's
identifier to message. Operator may use with the Authentication
service the value-added PersonIdentity-service. After receiving the
response message from HMSSP, operator shall show to user in Web
channel the information to be sent to AP. The user has in this phase
the possibility to accept or reject the authentication event. After the
acceptance, operator returns to AP the requested information.
If the Authentication service is not used in the Web channel,
where the information forwarded to the user can be shown so that
the user may confirm the sending of information to AP, the
information to be forwarded must be shown to user in the
signature request. It is the AE's obligation to compile the message
shown to user so that it specifies the information on user to be
sent to AP. AE also has to verify that the content of messages
accepted by user is unique.
Fig. 7 shows the user experience in Operator Authentication
service (Technical Service Description – Operators' Mobile
Certificate Service, 2010). The first screen shows the message
produced by the operator by using the AP's authentication request.
The length of message is not greater than 160 characters. If the user's
information transmitted to AP is not shown on Web channel, the
information has to be shown on the first screen. The second screen is
a standard-form request to input authentication SPIN for confirming
consent. The third screen is an optional receipt message sent by
108 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114

Internet Internet

MSSP Platform MSSP Platform

Anonymous The following informa- Welcome to

authentication tion about you will be Input authentication net-shop
request: 7J39L provided to the service SPIN: of Company Ltd
provider:
Sent by: ****
Company Ltd Age, gender

OK Return OK Return OK Return OK

Fig. 5. User experience in anonymous authentication.

Authentication The following informa- Welcome to

request: 7J39L tion about you will be Input authentication net-shop
provided to the service SPIN: of Company Ltd
Sent by: provider:
Company Ltd ****
SATU, Name, HETU

OK Return OK Return OK Return OK

Fig. 6. User experience in authentication service.

Service, 2010). The first screen is again the same as before but now
Bank Ltd: Payment to account
Confirm the Input authentication 102040-1233457
presented as a signature event. The second screen is the same as in
payment 3750 € SPIN: confirmed clear text signature service. The content of third screen is composed
to account
102040-1233457 **** by HMSSP by using the hash sent by AP. Introduction text and the
Ref. number whole hash value, or the last 16 octets of hash value in hexadecimal
123456-7
form, are shown to the user, depending on operator's choice (Fig. 8).
OK Return OK Return OK
For the sake of clarity, hash value should be presented in four
characters groups both on service channel and on the signature
Fig. 7. User experience in Operator Authentication service. channel (mobile phone). The hash value sent by AP is signed in UICC.

operator’s proxy-service about success or failure of the event. The

4.1.5. Clear text signature
content of receipt message may be freely decided by operator/AP.
In signature service, message sent by SP will be signed by using
user's private key, the purpose of which is non-repudiation. The
hash value is calculated inside the UICC of user’s mobile phone
4.1.4. Hash signature
from the message shown to the user. Hash value is signed by using
Document hash signature service is intended for applications
user's private key.
which require the advanced electronic signature of the user on
Different keys for authentication and for non-repudiation
some digital document. The document has to be shown to user on
(signing) are used.
Web channel where also the hash value calculated by AP from the
Fig. 9 shows the user experience in clear text signature service
message has to be shown. The user signs the hash value by using
(Technical Service Description – Operators' Mobile Certificate Service,
her private key (non-repudiation). The hash value is calculated
2010). The first screen is same as in authentication service, but the
from the content to be signed by using SHA-1 algorithm.
event is shown as a signature event. On second screen, the user sees
Hash signature service is intended for service providers who have
the information about her to be transmitted to AP. The con-tent
created a service for trusted validation of documents' electronic
depends on the parameters the AP has requested in the
signatures. Signature service provider has to take care also of
PersonIdentity-service. The third screen shows the content to be
administration and processing of the information associated with
signed. The content is fully decided by AP. The fourth screen is again
the documents, electronic signatures, user certificates and other
the same as before, in this case the SPIN for signing shall be inputted.
information, in such a way that the parties may uniquely verify the
validity of the legal transaction. This may happen, for example, so
that the signature service provider signs by her private key the whole 4.1.6. Consent
packet consisting of the document to be signed, electronic signatures, The consent service is intended for confirmation of the legal
user's certificates and other possible associated information. transaction in connection with service event. AP may, for example,
Fig. 8 shows user experience in document hash signature request consent from user to accept the terms of agreement
(Technical Service Description – Operators' Mobile Certificate ordered by the user.
 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114 109

Signature request: The following informa - Digest to be signed: User profile changed
7J39L tion about you will be Input signature
provided to the service 6F3C EE46 SPIN: Regards:
From: provider : AA3E 2399 Company Ltd
Company Ltd 7A5D 13A6 ****
Name, HETU AD3F 2C9F

OK Return OK Return OK Return OK Return OK

Fig. 8. User experience in document hash signature service.

Signature request: The following informa- I confirm to decommis- Request received to

7J39L tion about you will be sion from traffic car: Input signature decommission from
provided to the service Subaru Outback, SPIN: traffic car: FHV-758
From: provider: license number:
Finnish Transport FHV-758 **** Regards:
Safety Agency, TraFi Name, HETU From: March 1, 2012 Finnish Transport
Safety Agency, TraFi

OK Return OK Return OK Return OK Return OK

Fig. 9. User experience in clear text signature service.

Certificate Service, 2010; FiCom Implementation Provisions for ETSI MSS

Bank Ltd: Payment to account
Confirm the payment Input signature 102040-123 3457
Standards, 2012)
3750 € to account SPIN: confirmed
102040-1233457
 spam prevention code
Ref. number ****
123456-7  event identifier (transaction verification)
 archive service
OK Return OK Return OK
 services related to person's identity

Fig. 10. User experience in consent service.

The consent service should only be used in an application
where the user has already been strongly authenticated and where
the consent to be given is associated to the session opened. The
consent service may be used also in telephone conversation or in
face-to-face request of consent.
Fig. 10 shows the user experience of consent service (Technical
Service Description – Operators' Mobile Certificate Service, 2010). AP
sends through the service the signature request to the user. The
signature request shall include the text shown to user at signature
event which the user accepts. The text shown to user bearing her
signature is returned to AP as a response to successful signature request.
The PersonIdentity-service is not allowed to be used in con-
nection with consent service.
The message on first screen shall fulfill the following
requirements:
 the message content shall be such that the same user cannot
receive two messages of the same content for approval
(uniqueness)
 message is no longer than 160 characters
 the message must uniquely show who is requesting the
consent
 the message must uniquely show which legal transaction the
user is accepting
The second screen is same as in other signature services. The
third screen is optional receipt message sent by AP about the
success or failure of the event. The content of this screen may be
decided by AP.
4.2. Value-added signature services
In Finnish mobile signature service, the following value-added signa-
ture services are defined (Technical Service Description – Operators' Mobile
Value-added signature services increase the security and user
experience of mobile signature service. Some of the value-added
signature services are mandatory and some optional, decided by
service provider.
Service provider requests the value-added signature service
defined in signature request. The request may include also other
content related data. The service is implemented by service
provider's operator (Technical Service Description – Operators'
Mobile Certificate Service, 2010; FiCom Implementation Provisions
for ETSI MSS Standards, 2012).
In addition to the traditional security threats, two other threats
in mobile signature service are obvious; to spam mobile phone by
unauthorized signature requests, and to link the signature request
to wrong session.
ETSI standards do not offer ready-made solution to these
threats. In the Finnish scheme, those threats are protected by
using two value-added services; spam prevention code and event ID
(Technical Service Description – Operators' Mobile Certificate
Service, 2010; FiCom Implementation Provisions for ETSI MSS
Standards, 2012).
The use of spam prevention code and event ID in signature
request flow and in signature messaging level, in Figs. 3 and 4, are
explained respectively.
4.2.1. Spam prevention code
The mobile phone number given on AP's service channel as the
contact information for the signature request is not enough
because of security reasons. It would be possible to mislead the
AP to send signature requests to mobile phones of other users
(spamming). If the user is attacked in this manner, she would sign
the signature request and the attacker would succeed in hijacking
the user's identity and access to the service. Even if the user does
not sign false requests, there nevertheless is a danger that user's
mobile phone will be spammed and that the user loses trust in the
mobile signature service.
110 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114

Table 2
Security services on variety of service channels.

Channel Description

Open www-service (e.g. net-
shop)
Closed www-service (e.g. net- User is generally authenticated by weak means (e.g. ID/password). Use of spam prevention code is not mandatory.
bank)
Mobile Internet service
Mobile application
SMS service
Voice-call service
Face-to-face service
Service based on NFC/RFID
technology
User is generally not authenticated before responds to the signature request. Use of the spam prevention code is mandatory if it is not
possible to authenticate the user by other means (e.g. by cookie) and that on authentication, the phone number stored earlier may be
utilized.
User's phone number may potentially be obtained from the operator based on IP-address. In this case, the signature request may be sent
to user’s phone number and the spam prevention code is not necessary.
If user has an identifier created for service associated to the application, and the phone number is connected to identifier, the spam
prevention code is not mandatory.
User is authenticated weakly based on the phone number of calling party. Spam prevention code is not necessary. For example, a time
stamp is used as an event ID.
User is authenticated weakly based on phone number of calling party. Spam prevention code is not necessary. For example, a time stamp
is used as an event ID.
Authentication request may be sent to phone number informed by user without the spam prevention code. For example, a time stamp
may be used as an event ID.
User may be near-authenticated and the signature request may be sent without spam prevention code to the phone number already
known by application provider. For example, a time stamp may be used as an event ID.

The purpose of spam prevention code is to prevent disturbing
the user's mobile phone with unwanted requests. User sends her
spam prevention code to AP on service channel. AP sends the code
to HMSSP. If the code is missing or not the same as the one stored
in user's profile, HMSSP interrupts the service requested.
The AP may authenticate the user in some other way before
sending a signature request. In this case, the AP does not have to
request the spam prevention code from the user.
The length of spam prevention code should not be less than
three characters. The user may set the spam prevention code on
her mobile phone at operator service desk or on self-service
portal. Spam prevention code is optional but in some cases the
AP may ask the user for the spam code (Table 2).
4.2.2. Event ID
The primary purpose of the event ID is to ensure that, when
accepting a signature request, the user knows which event it is
related to.
For each signing operation, a unique event ID (short form of
digital fingerprint) for that transaction is created by AP (e.g. the
bank). User compares the out-of-band event ID on her mobile
phone (signature channel) with that one on her computer screen
(service channel), before completing the signing process. Event ID is
shown on both channels at the same time, if possible (two-terminal
model). If it is not possible to present the code on service channel
simultaneously (one-terminal mode), AP should add a time stamp
or some other individual information related to signature request.
The length of event ID should not be less than four characters.
Event ID is mandatory.
4.2.3. Archive service
Service provider (AP) may request AE for an archive service by
which the information related to signature request (signature request
and response messages) will be archived on behalf of AP. The service
needs an agreement with AP and depends on AE implementation.
4.2.4. Services related to person's identity
Service provider may ask in signature request additional
information related to user's identity by using value-added service
called PersonIdentity. The additional information (attributes)
offered are: HETU, SATU, postal address, age, age class, e-mail
address, gender, given name, surname, subject, and valid until.
Attributes are coded in SAML assertion format.
The signature request flow including the PersonIdentity-service
is shown in Fig. 11 (Technical Service Description – Operators'
Mobile Certificate Service, 2010). The different phases in signature
request flow in Fig. 11 are following:
AP sends request including PersonIdentity-service (in SAML
format) (phase 1). AE validates the AP's rights to attributes
requested (phase 2). AE forwards the request to HMSSP (phase 3).
HMSSP checks that the attributes requested are allowed to signa-
ture service requested (phase 4). HMSSP sends the request to user
for approval (adds the screen text of the information requested)
(phase 5). HMSSP completes the SAML request with user's SATU
and makes a request to its own attribute service (phase 6). Attribute
service fetches the information requested, composes and signs the
SAML assertion and returns it to HMSSP (phase 7).
HMSSP completes the response message with SAML assertion
and returns the information through AE to AP (phase 8). AE
returns the response message to AP (phase 9).
Application provider receives the attributes requested in the
SAML assertion signed by the user's home operator. Service
provider may, if wishing so, validate the information transmitted
by using public key of the home operator.
5. Service security and trust
Service security and trust in Finnish mobile signature scheme is
based on strong security of mobile networks and SMS channels, strong
mobile PKI security, separate authentication and non-repudiation
(signing) SPINs, preventing the signature spams, preventing the sign-
ing of wrong sessions, mutual security arrangements in Circle of Trust
(CoT), security and validation of the signature requests, and on the
agreements with application providers (Technical Service Description
– Operators' Mobile Certificate Service, 2010).
All communication links between all parties in the CoT are
encrypted and are based on strong mutual authentication. In
stakeholders' networks the high-level industry-standard firewalls
are used.
5.1. Validation of signature requests
Response to signature request is sent to AP as MSS_Signature-
Resp message. MSS_SignatureReq message contains the informa-
tion needed to authenticate the user and the content signed by the
user, and the eventID and timestamp issued by AP for the event.
Correspondingly, the HMSSP/AE will enter the time stamp in the
response message. The service messages are currently not XML-
signed. Security of the service messages are based on mutual
security of the communication networks in the CoT. In addition,
 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114
AP User
1 9 5
AE HMSSP
2 4 6 7
Attribute Attribute
service of AE
service
Fig. 11. Processing of PersonIdentity-service.
the integrity and authenticity of MSS_Signature elements may be
validated by the operator of AP.
5.2. Service agreement
AP is connected to operators' mobile signature service by
making a Service agreement with the selected mobile operator.
The agreement defines the responsibilities and duties, as well as
the signature services used by AP.
Each application provider has unique identifier AP_ID and
unique name. The name is shown to user as part of signature
request (not, however, in the case of consent service). AP's
operator sends new AP_ID and AP's name to other operators.
AP_ID will be used by the parties participating in message routing.
In the agreement, the signature profile, or the services AP will
utilize, is defined. Outside the profile, the use of other services is
not possible.
5.2.1. Restriction of signature services
The Service agreement shall define the signature and value-
added services the AP may use (Technical Service Description –
Operators' Mobile Certificate Service, 2010). If the right to use
PersonIdentity-service is included in the agreement, it will define
the attributes the AP may use on the service interface.
For each signature service of value-added PersonIdentity-service,
HMSSP defines what is permitted. The operator may, if so wishing,
make these definitions based on the user so that the user may restrict
in the self-service portal the information about her to be sent to AP.
Related to anonymous authentication, the operator will restrict
in the PersonIdentity-service such information to be returned to
the AP which may reveal user's identity.
The ‘Identification’ Act has an option for the user to set
restrictions in using the signature device in legal transactions.
This option is included in Finnish mobile signature service.
5.3. Security services on various channels
The service provider may use in flexible ways and depending
on the characteristics of the service channel, mobile signature and
value-added services and other security means, on various ser-
vices and service channels (Table 2) (Technical Service Description
– Operators' Mobile Certificate Service, 2010).
111
7 8
5 6
3 4
1 2
PKI-based two-factor, two-channel (2F2C) signature model
Tamper-proof secure element for signatures (UICC/SSCD)
Mobile operators’ secure SIM/USIM logistics
Operators’ secure networks (3G/4G/SMS, RA-CA-MSS-SP)
Federation of security assertions/ETSI MSS standards/CoT
Spam prevention and out-of-band transaction verification
Diversity of mobile phones minimizes large scale attack risks
My mobile phone is ’my personal identity’ and ’signing device’
Fig. 12. ‘Security cornerstones’ in Finnish federated strong mobile signature
service.
Application provider may ask user authentication and digital
signing either online or offline, and remotely or locally, depending
on the service configuration.
5.4. ‘Security cornerstones’
Finnish federated strong mobile authentication and digital
signature service platform has several security measures, or
‘security cornerstones’, shown in Fig. 12. This model is much more
secure than those existing online schemes based on one- or two-
channel and two-factor models.
The service is based on PKI and two-factor, two-channel (2F2C)
signature model. The model supports authentication (user, origin),
non-repudiation (signing) and content verification, and therefore
technically also legally binding signatures.
Mobile operators have a secure element (SE), the UICC, inside the
mobile device. With the SE and the SIM Application Toolkit (SAT)
operators have created trusted usage of mobile signature services.
Personal secure credentials are located and the crypto-
operations performed in WPKI client inside the USIM on tamper-
proof UICC. The UICC is a standardized, trusted operator anchor in
the user domain in 2 G, 3 G and open access 4 G networks. All
mobile services rely on high level of security of the UICC.
Mobile operators have more than twenty years or experience
about efficient and cost-effective SIM logistics. This open distribu-
tion model is both efficient and beneficial to users, operators and
equipment vendors.
Mobile operators control and manage their networks where
the reliable and trusted authentication and digital signing services,
as well as secure communications, are provided. 2 G, 3 G and 4 G
networks with very popular SMS messaging combined with strong
encryption between the network elements RA, CA, MSS and SP
provide the basis of the Finnish mobile signature model.
The architecture is based on the federation of security asser-
tions in Circle of Trust (CoT) using ETSI Mobile Signature Service
standards.
The service has integrated spam prevention and out-of-band
event verification services which further increase the security and
trust of the transactions.
112 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114

Table 3
Usability and versatility of Finnish mobile signature scheme compared with other authentication schemes.

Feature Scheme

PIN / TAN Password OTP EMV Cardþ Reader(OTP Mobile SMS- PKI Smart Finnish Mobile Signature
List Token Token) OTP Cardþ Reader

Security Weak Average Average Average High High

Easy to use High Weak Weak Average Weak High
Mobility Average Weak Weak High Weak High
Low usage cost Average Average Average High Average High
Low distribution cost Weak Weak Weak High Average High
Low maintenance Average Average High High Average High
All-purpose Weak Weak Weak Weak Weak High
versatility
Legal qualified Weak Weak Weak Weak High High
signing

The diversity of mobile devices minimizes the risk for mass
scale security breaks, and makes the user devices more robust in
mobile world. Moreover, malwares are user-assisted. There are no
self-spreading malware. Therefore, attacks are not easy to perform
on mass scale format.
In mobile, the attack vectors are very much different from each
other and attacks are case-by-case attacks.
The mobile handset, or device with embedded UICC, by which
the authentication and signing is provided, is very personal device,
raising the feeling about ‘my mobile identity’ and ‘my signing-tool’.
In addition, the popular Finnish PIN/TAN system ‘Tupas’, or
Bank ID, developed by financial industry, may be used for pre-
authentication in online registration and certificate issuing process
in the Finnish mobile signature service. ‘Tupas’ gives unique
advantage to launch quickly the signature services to mass market.
Mobile SMS-OTP is easy to use and low cost, it is mobile, and it
does not need maintenance.
PKI smart card with reader is very secure and is suited for legal-
binding signing. However, this scheme is not easy to use and it is
not mobile, and the costs are not low. The reader software needs
maintenance.
Finnish mobile signature scheme (Mobile ID) is the only
scheme in Table 3 which is very secure and easy to use, truly
mobile, low cost, does not need maintenance, it is all-purpose
versatile and provides technically the legal-binding signing.
The Finnish scheme is the only authentication scheme which
provides the Circle of Trust and which supports the same user-
experience across all service channels, including Internet, mobile,
voice and video.
Operator manages the UICC, and the distribution costs are
covered by existing UICC logistics.

6. Versatility 6.2. System performance

Suitability of the Finnish mobile signature service for the
consumer market and the versatility to different use-cases and
applications is discussed here by comparing the service with other
authentication schemes in the same market, and examining the
performance of the signature scheme.
6.1. Comparison with other schemes
In Table 3 the Finnish mobile signature scheme with other
common authentication schemes on consumer market from the
security, easy to use, mobility, usage cost, distribution cost,
maintenance, all-purpose versatility and legal qualified signing
point of view are compared. The features in Table 3 in (Nĕmec,
2012) and (Saharanta, 2008) also are discussed. All-purpose
versatility means Circle of Trust, multi applications, multi service
channels, remote usage (from anywhere, at any time), etc.
The banks' PIN/TAN with password list is weak in security, in
all-purpose versatility and legal-binding signing.
PIN/TAN scheme is easy to use but it is bank-dependent.
Businesses have often had to execute at least ten separate agree-
ments and integrations with banks, each with its own fee
structure and certificate scheme. Some public service authorities
offering multiple services have had to execute up to tens of
separate agreements with different banks (Finnish Mobile ID – A
Lesson in Interoperability, 2013).
PIN/TAN schemes and OTP tokens need maintenance of the
bank or token issuer.
Security of the OTP tokens, EMV Card with reader and mobile
SMS-OTP is on the average level. All these three schemes, however,
are not all-purpose versatile and are not suited for legal-binding
signing.
The performance of Finnish mobile signature service can be
estimated from the system tests measured by MSSP vendors. MSSP
vendor Methics Ltd (Finland) has given the results of their studies
performed in summer 2011(Kiuru MSSP Release 5, 2015). The test
system consisted of x86 platform (4-core CPU/64 bit/2,4 GHz/8
GB) as separate VMware virtual servers (running CentOS). The
MSSP configuration included all system components, i.e. vendor
designed and implemented AE and HMSSP, validation, and simu-
lated OTA (over to air), mobile phone and SIM, representing the
real user case as in Fig. 4. A single database engine, load generator,
and PKI simulator were located on a separate server. In tests the
PKI simulator uses RSA 1024-bit signing and SHA-digests. PKI part
in the test set-up has not been the bottleneck.
MSSP performance can be measured in several ways. User
experience related to the MSSP delay factor is one natural way to
measure the performance.
Fig. 13 shows the test results in asynchronous client–server and
server–server messaging mode. In the former mode the client is
polling with MSS_StatusReq the transaction response. In the latter
mode MSSP sends the transaction response to the service in thread
in the client (Fig. 4).
If MSSP system delay is required to be less than two seconds,
the performance of the test set-up is approximately 80 transac-
tions per second (tps).
If more than 100–150 active (HTTP 1.1 persistent) client con-
nections per MSSP instance are required, the performance can be
scaled by clustering. Clustering increases the performance nearly
linearly, or with two servers to about 150 tps, with 4 servers to
300 tps, and so on. In some point the database engine should also
be scaled. With optimized test set-up these figures would be
higher.
 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114
Fig. 13. MSSP system delay vs. load in Methics test.
7. Discussion
7.1. Infrastructure challenges
Main challenge earlier in Finnish mobile signature service has
been the lack of proper legal and technical infrastructure.
First time in the year 1999 SmartTrust, Sonera owned company,
launched a SIM-card based pilot. The first mobile certificate in the
world was launched by PRC that year. These early steps were
formative and groundbreaking, but too early. Capable handsets
and SIM cards, consumers’ Internet, as well as legislation, was not
sufficiently widely deployed.
The second real attempt was in 2005. The law at that time (Act
14/2003) stated that only the police department could issue the
strong identification. At that point, the registration process was
too difficult, so the Mobile ID failed.
7.2. Proven implementation and processes
Third time now from 2011 with better coordination, clarified
legislation, mobile devices, mobile signature standards, and a
greater number of service providers interested have all come
together to create an environment for the success of Finnish
mobile signature service.
The Finnish mobile signature service is a proof that new
technologies, standards and business processes work.
Compared to other consumer authentication schemes, the
Finnish mobile signature service is more secure, low cost, more
easy to use and all-purpose versatile.
The performance tests indicate that the Finnish mobile signa-
ture service is capable to serve successfully masses of users during
a busy hour.
There still are some challenges in the signature service to be
solved.
7.3. Pre-authentication
The major challenge is to have all banks to allow their Bank ID
(or ‘Tupas’) to be used in pre-authentication for online registration
to obtain a Mobile ID. One reason for resistance is the competition
between banks. The other reason is that transferring the trust from
customer registration and mobile certificates deeper to the bank's
113
business processes may cause worry. In addition, majority of banks
have their own certificate standards, formats and policies internally.
In Finnish mobile signature service, the pre-registration through
the Bank ID is a key milestone for facilitating scale and uptake among
users. The ability to issue Mobile ID “over-the-air” is based on the fact
that most UICCs in the field are Mobile ID capable already. This
process takes no more than three minutes and is therefore consid-
ered to be far more convenient to the customer than to visit to
operator store (Finnish Mobile ID – A Lesson in Interoperability,
2013).
7.4. Future challenges
One challenge is to extend the concept of Circle of Trust (CoT).
Discussions are on the way to include into CoT not only Mobile ID
but also Bank ID and Citizen ID card. In addition to the system
integration, the concept may help also in the challenge of pre-
authentication above.
New challenges may emerge in business use. For example,
when multiple users with different roles in a single company need
to use Mobile ID. The Finnish mobile signature scheme is designed
primarily for the cases where the businesses wish to authenticate
consumer clients.
One challenge also is a user-case scenario where the customer
authentication process needs to be quicker than over the mobile or
Internet channels, such as in-store payments, transport, in moving
queue, and similar.
In Finnish mobile signature scheme the time from starting to
feed SPIN to complete the signature transaction normally is
between 20 to 30 s. The main delay is resulted from transferring
and processing of few SMS messages.
For mobile signatures, the Finnish scheme uses 1024 or 2048-
bit RSA, and SHA-1/SHA-256/512 hash (Table 1). Processing these
functions does not cause significant delays.
For reducing the number of SMS messages, even to one
message per signature, ECC (Elliptic Curve Cryptography) algo-
rithm instead of RSA may be used.
For quick authentications, needed in queue applications, for
example, one technology is over the Near Field Communication
(NFC) channel. NFC eliminates the use of Internet and mobile
channels.
8. Conclusion
In this paper the Finnish federated strong mobile signature
service with its features and services and the platform security is
presented and discussed. The mobile signature service includes
several ‘security cornerstones’ making it unique, secure and trusted
open service for information society's signature needs. The perfor-
mance of service is high and proven for mass-scale usage.
The services in Circle of Trust may request mobile authentica-
tions and signings from user even if the service provider has made
an agreement with other than the user's home operator.
Finnish mobile signature scheme works in a variety of different
service channels, including voice, mobile data and video conferencing.
Signature services can be used abroad where SMS services are
provided and where user's operator has a roaming agreement.
The Finnish mobile signature service fulfils the strong identi-
fication in the Finnish Act on Strong Electronic Identification and
Electronic Signatures.
In e-commerce, in personal affairs, or everywhere in the
information society, the information integrity of and the confi-
dence in such functions (primitives) or services as proof of
identity, authenticity, authority, non-repudiation, seal, privacy,
access, ownership, license, witnessing or notarization, consent,
114 E. Kerttula / Journal of Network and Computer Applications 56 (2015) 101–114
date of action, certification of origination and/or receipt, voting,
validation, etc. will be crucial requirements.
Finnish mobile signature service will promise reliable and
secure, seamless and open framework for such functions and
services in all-purpose versatile usage.
Acknowledgments
Main part of this paper is based on consulting study of author
during 2009–2011 ordered by TeliaSonera Finland, Elisa, DNA and
FiCom. Author thanks the following people for comments and
improvements of the article: Pekka Turpeinen (TeliaSonera Fin-
land), Petri Kaurinkoski and Janne Niemensivu (Elisa), Lasse
Leppänen (DNA), Jouni Heinonen, Teemu Turu and Esko Heimonen
(Valimo Wireless, part of Gemalto), Jarmo Miettinen (Methics Oy)
and Pekka Jelekäinen (Population Register Centre).
References
Act on Strong Electronic Identification and Digital Signatures (617/2009), 〈www.
finlex.fi/en/laki/kaannokset/2009/en20090617.pdf〉.
Alenius Fabian, Bauknecht Uwe, Online Banking Security, May 17; 2009.
Erkki Saharanta, Value in Mobile, Valimo Wireless Ltd; 2008.
Esa Kerttula, Security of the user device in the Finnish mobile authentication and
digital signature infrastructure, unpublished consulting study for the Finnish
Mobile Operators, Prof-Tel Oy Ltd, March; 2009.
ETSI TR 102 203, Mobile Commerce (M-COMM), mobile signatures, business and
functional requirements 2003.
ETSI TR 102 206, Mobile Commerce (M-COMM), mobile signature service, security
framework; 2003.
ETSI TS 102 204, Mobile Commerce (M-COMM), mobile signatures, web service
interface; 2003.
ETSI TS 102 225, Smart cards, Secure packet structure for UICC based applications; 2003.
ETSI TS 102 207, Mobile Commerce (M-COMM), mobile signatures, specifications
for roaming in m-signature services; 2003.
European Union Directive 1999/93/EC on Community framework for electronic
signatures, 13 Dec.; 1999.
ec.europa.eu/digital-agenda/en/trust-services-and-eid.
FiCom Implementation Provisions for ETSI MSS Standards, v2.1, FiCom, Jan.; 2012.
Finnish Mobile ID – A Lesson in Interoperability, GSMA Mobile Identity, by Alix
Murphy, 〈www.gsma.com/〉 mobileidentity/resources, Feb.; 2013.
3GPP TS 11.14 v8.18.0 , Pecification of the SIM application toolkit for the subscriber
identity module – mobile equipment (SIM-ME) interface; 2007.
3GPP TS 23.040, Technical realization of the Short Message Service (SMS); 2010.
3GPP TS 23.048, Security mechanisms for the USIM application toolkit, Stage 2; 2005.
3GPP TS 31.111 v9.2.0, Universal Subscriber Identity Module (USIM) application
toolkit (USAT); 2010.
3GPP TS 43.019 v5.6.0, Subscriber Identity Module application programming
interface (SIM API) for Java Card; 2003.
3GPP TS 03.38, Alphabets and language-specific information for GSM.
GSMA Europe response to European Commission consultation on eSignatures and
eIdentification, GSMA, 15 April; 2011.
GSMA-SAS, Security Accreditation Scheme - Standard, GSM Association, Sept.; 2008.
Jan Nĕmec, Mobile ID, Smart Cards & Devices Forum 2012, Gemalto ; 2012.
JavaCard 2.2, Java Card ™ 2.2 Platform Specification, Oracle.
Kiuru MSSP Release 5, Mobile Signature Service, Solution Overview, V.1.30, Methics
Ltd; 2015 (confidential).
OATH Reference Architecture, Rel. 2.0; 2007.
Personal Data Act (523/1999), 〈www.finlex.fi/en/laki/-kaannokset/1999/
en19990523〉.
PKCS#1, RSA Cryptography Standard, RSA Laboratories; 2002.
PKCS#10, Certification Request Syntax Standard, RSA Laboratories; 2000.
PKCS#7, Cryptographic Message Syntax Standard, RSA Laboratories; 1993.
RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol
– OCSP, IETF June; 1999.
RFC 3647, Internet X.509 Public Key Infrastructure Certificate Policy and Certifica-
tion Practices Framework, IETF; 2003.
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and certificate
revocation List (CRL) Profile, IETF May; 2008.
RFC 5652, Cryptographic Message Syntax (CMS), IETF; 2009.
SAML v2.0, Security Assertion Markup Language v2.0, Oasis; 2005.
XML Schema P1, P2, XML Schema Part 1: Structures Second edition, W3C (Oct.
2004), XML Schema Part 2: Datatypes Second Edition, W3C, Oct.; 2004.
SOAP 1.2, Simple Object Access Protocol, version 1.2 Part 1: messaging framework,
W3C; 2003.
Technical service description – Operators’ mobile certificate service, v1.0, DNA,
Elisa, TeliaSonera, Dec.; 2010.
TUPAS Identification Service, Identification principles V2.0, Federation of Finnish
Financial Services, 15 March; 2010.
UCS-2, 2-byte Universal Character Set; UTF-8, Unicode Transformation Format -8
(octet).
VIP Access for Mobile: Making consumer two-factor authentication simple and
cost-effective, White paper, Verisign; 2010.
WDSL 1.1, Web Service Definition language, version 1.1, W3C; 2001.
〈www.fineid.fi〉.
〈www.mobiilivarmenne.fi/en/index.html〉.
〈www.ficora.fi/en/etusivu.html〉.
X509v3, X.509, Information technology – Open Systems Interconnection – The
Directory: Public-key and attribute certificate frameworks, ITU-T; 2005.
XML Signature, Joint IETF/W3C Specification; 2008.