Content uploaded by Kyung Hyune Rhee
Author content
All content in this area was uploaded by Kyung Hyune Rhee on Dec 01, 2015
Content may be subject to copyright.
An Efficient Authentication and Simplified
Certificate Status Management for Personal
Area Networks?
Chul Sur1and Kyung Hyune Rhee2
1Department of Computer Science, Pukyong National University,
599-1, Daeyeon3-Dong, Nam-Gu, Busan 608-737, Republic of Korea
kahlil@pknu.ac.kr
2Division of Electronic, Computer and Telecommunication Engineering,
Pukyong National University
khrhee@pknu.ac.kr
Abstract. Recently the concept of personal PKI was introduced to de-
scribe a public key infrastructure specifically designed to support the dis-
tribution of public keys in a personal area network. However, traditional
public key signature schemes and certificate status management schemes
used in the personal PKI concept cause formidable overheads to compo-
nents in the personal area network since mobile devices constituting the
personal area network have limited computational and communication
capabilities. In this paper we propose an efficient authentication protocol
that eliminates the traditional public key operations on mobile devices
without any assistance of a signature server. Moreover, the proposed pro-
tocol provides a simplified procedure for certificate status management
to alleviate communication and computational costs on mobile devices
in the personal area network.
1 Introduction
A Personal Area Network (PAN) is the interconnection of fixed, portable, or
moving components within a range of an individual operating space, typically
within a range of 10 meters. In PAN the communication between components
should be secure and authenticated since private information and personal data
will be transmitted over radio links. Secure and authenticated communication
can be achieved by means of proper security protocols and appropriate security
associations among PAN components.
For the sake of supporting key management in a PAN, a personal CA, which
is responsible for generating public key certificates for all mobile devices within
?This work was partially supported by grant No. R01-2006-000-10260-0 from
the Basic Research Program of the Korea Science & Engineering Foundation,
and the MIC(Ministry of Information and Communication), Korea, under the
ITRC(Information Technology Research Center) support program supervised by the
IITA(Institute of Information Technology Assessment).
the PAN, was introduced in [3]. The personal CA is used by an ordinary user
at home or small office deployment distinguished from large scale or global CA
functions. Nevertheless, in order to use a personal PKI technology as like a
conventional PKI technology, this concept assumes that at least one device in
the PAN acts as a personal CA so as to issue certificates and provide certificate
status management to all other devices. Therefore, all the personal devices can
be equipped with certificates issued by the same CA, i.e., the personal CA, while
sharing a common root public key. As a result, mobile devices in the PAN can
establish secure and authenticated communications with each other by means of
certificates. The initialization phase of [3] extends the concept of imprinting [12]
to bootstrap all mobile devices with public key certificates. After all the mobile
devices have been imprinted with their public key certificates, mobile devices
may launch routine operations of the PAN by means of the traditional public
key signature schemes.
The personal PKI concept seems to be properly applied to PAN environment.
However, the personal PKI concept leaves at least two important challenging
problems unaddressed. The first challenging problem to think about is that: The
traditional public key signature schemes put resource-constrained mobile devices
to formidable workloads since a digital signature is a computationally complex
operation. The second challenging problem is that: To manage certificate sta-
tus information, no optimization was devised and the conventional certificate
status management schemes were considered. Consequently, to design efficient
authentication protocol and certificate status management that addresses the
aforementioned problems is a promising challenge for PAN environment.
In this paper, we propose an efficient authentication protocol that reduces
computational overheads for generating and verifying signatures on mobile de-
vices. Especially, we focus on eliminating the traditional public key operations
on mobile devices by means of one-time signature scheme, and we differentiate
it from previously proposed server-assisted computation approaches relied on
assistances of a signature server. As a result, the proposed protocol gets rid of
inherent drawbacks of server-assisted computation approaches such as problem-
atic disputes, and high computational and storage requirements on a server side.
Moreover, our protocol provides simplified certificate status management based
on hash chain technique to alleviate communication and computational costs for
checking certificate status information.
2 Preliminaries
2.1 One-Time Signatures and Fractal Merkle Tree Traveral
One-time signature (OTS for short) schemes are digital signature mechanisms
which can be used to sign, at most, one message[7]. One-time signature schemes
have the advantages that signature generation and verification are very efficient,
and further, more secure since these schemes are only based on one-way func-
tions, as opposed to trapdoor functions that are used in traditional public key
signature schemes.
Despite of aforementioned advantages, one-time signature schemes have been
considered to be impractical due to two main reasons: (1) the signature size is
relatively long in comparison with traditional public key signatures. (2) their
”one-timed-ness”, i.e., key generation is required for each usage, thus implying
that the public key must be distributed in an authentic fashion which is done
most typically using a public key signature. As a result, the benefit of usefulness
of quick and efficient one-way function is apparently lost.
In order to decrease the length of one-time signatures, a message digest
should be calculated using hash function, just like traditional public key sig-
nature schemes, and then one-time signature scheme should be applied to the
message digest. In this case, if a message digest would be the SHA-1 function
which has a 160 bits output, we need 168 secrets to sign the message digest[7].
Merkle introduced the idea of using a hash tree to authenticate a large num-
ber of one-time signatures[8]. An important notion in Merkle’s proposal is that of
an authentication path: the values of all the nodes that are siblings of nodes on the
path between a given leaf and the root. In [5], Jakobsson et al. presented a fractal
Merkle trees for the sequential traversal of such a Merkle hash tree, which pro-
vides the authentication path for each leaf when the leaves are used one after the
other. In this scheme, the total space required is bounded by 1.5log2N/loglogN
hash values, and the worst-case computational effort is 2logN/loglogN hash
function evaluations per output. Recently, Naor et al. showed that the combined
scheme of Merkle’s one-time signature scheme with Jakobsson et al.’s algorithm
provides fast signature times with low signature sizes and storage requirements
through experimental results[9].
2.2 Hash Chain
The idea of hash chain concept is based on the property of a one-way hash
function h() that operates on arbitrary-length inputs to produce a fixed length
value. One-way hash functions can be recursively applied to an input string. The
notation hn(x) denotes the result of applying h() ntimes recursively to an input
x. That is,
hn(x) = h(h(h(. . . h
| {z }
n times
(x). . .)))
Such recursive application results in a hash chain that is generated from the
original input string:
h0(x) = x, h1(x), . . . , hn(x)
In most of the hash chain applications, first hn(x) is securely distributed and
then the elements of the hash chain is spent one by one starting form hn−1(x)
and continuing until the value of xis reached.
2.3 Modified Efficient Public Key Framework
In [13], Zhou et al. proposed a new public-key framework, in which the max-
imum lifetime of a certificate is divided into short periods and the certificate
could expire at the end of any period under the control of the certificate owner.
They intended to establish a new public key framework that exempts the CA
from testifying the validity of a certificate, once the certificate has been issued
by the CA. However, Zhou’s framework has considerable problems for practical
implementation. That is, it is an unreasonable framework to authenticate an
unidentified user based on some information submitted by the unidentified user
in exempting CA. In particular, a malicious user can always generate valid sig-
natures without any restriction. To overcome this drawback, they introduced a
new trust party called security server. However, the security server is not only a
redundant entity, but also requires an additional cost to be maintained securely.
Alternatively, we introduce control window mechanism to make Zhou’s public-
key framework above more suitable for realistic implementation.
Definition 1 (Control Window). Control Window describes a time period
that the verifier can trust the status of the sender’s certificate only based on the
sender’s hash chain.
Upon control window mechanism, CA sets the size of the control window of
the user at the certificate issuance. The user can control the status of his/her
certificate by using hash chain, and the verifier only trusts the user’s hash chain
during the control window. At the end point of the control window, the verifier
queries certificate status information to CA.
3 System Model
3.1 Design Principles and Architecture
In this section, we firstly clarify our design principles in order to efficiently
provide authentication and certificate status management among mobile devices
in PAN environment. The concerns of our design are summarized as follows:
–Eliminating Public Key Operations on Mobile Devices. Since traditional pub-
lic key signature schemes generally require computationally complex opera-
tions in terms of signature generation and even verification, they may not
even be appropriate for resource-constrained mobile devices in PAN, which
may have 8-bit or 16-bit microcontrollers running at very low CPU speeds.
Therefore, designing an authentication protocol which does not perform any
public key operations is a promising challenge in PAN environment.
–No Assistance of a Signature Server. To avoid cumbersome public key sig-
nature generations, some cryptographic protocols which depend upon a sig-
nature server were presented[1][2]. However, these approaches put a heavy
burden on the server side or, both the server and the mobile device side in
terms of high storage requirement for resolving problematic disputes. Fur-
thermore, these approaches do not eliminate public key operation on verifier
side and suffer from round-trip delay since all signing procedures are carried
out through the signature server. Consequently, it is desirable to design an
authentication protocol without assistances of the signature server.
–Small Computational and Communication Overheads for Validating Certifi-
cate Status. Although online certificate status checking mechanism such as
OCSP[11] seems a good choice since mobile devices can retrieve timely cer-
tificate status information with moderate resources usages in comparison
with CRLs[4], the personal CA suffers from heavy communication work-
loads as well as computational overheads as it requires computing lots of
signatures. Therefore, to mitigate the personal CA’s workloads, it is neces-
sary to reduce the number of the personal CA’s signature generations and
total communication passes.
To define architectural model more clearly, we assume the followings:
–A PAN consists of portable or moving components that communicate with
each other via wireless interfaces.
–At the constituting the PAN, all the security associations required for mak-
ing PAN routine operations secure are set up. That is, every mobile device
equipped with the PAN is bootstrapped with these security quantities and
certificates during the initial phase.
A PAN is composed of a personal CA and mobile devices in our system
model. The descriptions of system components are as follows:
– Personal CA : Personal CA is a unique trusted third party in the PAN,
and it has a display and a simple input device to give its commands. Also, it
is permanently available online to provide all other PAN components with
certificates and certificate status information.
– Mobile Devices : Components equipped with the PAN, which have net-
working capability and likely low computing power.
3.2 Notations
We use the following notations to describe the protocols:
–P CA, M : the identities of personal CA and mobile device, respectively.
–h() : a cryptographic secure one-way hash function.
–SKX: a randomly chosen secret key of the mobile device X.
–ski,j
X: the secrets of each one-time signature of the mobile device X, where
ski,j
X=h(SKX|i|j)
iis the signature number, jis the index of the secret, and |is the concatenation
of messages.
–pki,j
X:= h(ski,j
X) : the commitments for each ski,j
X.
–P LCi
X:= h(pki,1
X|···|pki,t
X) : the i-th public leaf commitment, which is the hash
of all the commitments of a single one-time signature.
–P KX: a public key of the mobile device X, which is the tree root of a fractal
Merkle hash tree.
–AuthP athi
X: the authentication path of the i-th public leaf commitment of the
mobile device X.
–V Kn−i
X: the i-th validation key of the mobile device X. Based on a randomly
chosen secret quantity V KXfrom the range of h(), the mobile device Xcomputes
the hash chain V K0
X, V K 1
X,···, V K n
X, where
V K0
X=V KX, V K i
X=hi
X(V KX) = hX(V Ki−1
X)
V Kn
Xconstitutes X’s root validation key,V Kn−i
Xis X’s current validation key.
–Sigi
X: the i-th one-time signature of the mobile device X.
–CertX: a certificate of the mobile device X.
4 Proposed Protocol
In this section, we present an efficient authentication protocol that provides
fast signature generation and verification without any assistance of a signature
server, and offers simplified certificate status checking by means of control win-
dow mechanism.
Initialization. The initialization of mobile devices is the modified version of
manual authentication protocol[3] that inherently settles key distribution prob-
lem in one-time signature scheme. The detailed steps are as follows:
Personal CA Mobile Device
PCA
PKPCA ,
n
MM VKnPKM ,,,
i
PCAM AuthPathCert ,
Compute
),,,,,( n
MMPCAk VKnPKMPKPCAMAC
Recompute
),,,,,( n
MMPCAk VKnPKMPKPCAMAC
Fig. 1. System Initialization
1. The personal CA sends its identifier and public key to a mobile device.
2. The mobile device randomly generates two secret quantities SKMand V KM.
Starting with these values, the mobile device performs the followings:
–Generates the one-time secrets/commitments pairs and the corresponding pub-
lic leaf commitments according to the total number of signatures n(Taking
into account the PAN environment, we assume that the total number of sig-
nature is less than 216).
–Initializes a fractal Merkle hash tree of height logn, and computes a public key
P KM, with the public leaf commitments values P LC i
Mas its leaves, where
i= 1,···, n.
–Generates V Kn
M=hn(V KM) as the root validation key.
–Sets the signature number i= 0.
Then, the mobile device submits M, P KM, n, V K n
Mto the personal CA.
3. Both the personal CA and the mobile device carry out the following manual
authentication:
–The personal CA generates a random key kand computes a MAC as a function
of P CA, P KP CA , M, P KM, n, V K n
Mby using the random key k. The MAC and
the key kare then displayed by the personal CA.
–The user now types MAC and kinto the mobile device, which uses kto recom-
pute MAC value (using its stored versions of the public keys and associated
data as input).
If two values agree then the mobile device gives a success signal to the user.
Otherwise it gives a failure signal.
4. If the mobile device emits a success indication, the user instructs the personal
CA to generate a certificate. In order to generate the certificate, the personal
CA sets up a control window CW according to the system security policy
and issues the certificate signed by one-time signature for the mobile device
together with the authentication path AuthP athi
P CA of the certificate.
CertM={Ser#, M , P KM, n, V K n
M, CW, S igi
P CA }
, where Ser# is a serial number.
5. The mobile device checks the followings to verify the correctness of the issued
certificate.
–Verifies the one-time signature of the personal CA on the certificate by the use
of P KP CA and AuthP athi
P CA .
–Checks whether the data fields within the certificate are valid as expected.
If all the checks are successful, the protocol is now completed.
As described above, every mobile device is bootstrapped with a pair of pub-
lic/secret key and its own certificate during the initial phase. After all mobile
devices have been imprinted with their security quantities, mobile devices which
wish to sign and verify a message carry out the following signature genera-
tion/verification phase.
Signature Generation. A mobile device Mswhich wishes to sign a message
mperforms the followings:
–Proceeds Merkle’s one-time signature scheme[7] as follows:
•Increments the signature number i
•Calculates a message digest md =h(m) and sets C= number of ’0’-bits in
md, and then sets msg =md||C.
•Generates {ski,j
Ms}t
j=1 and the corresponding {pki,j
Ms}t
j=1, where t=|msg|.
•Calculates Sigi
Ms={ski,j
Ms∀j∈ {j|msgj= 1}, pki,j
Ms∀j∈ {j|msgj= 0}}.
–Computes AuthP athi
Msand updates authentication path using fractal Merkle tree
algorithm[5].
–Calculates the current validation key V Kn−i
Ms.
Then, sends m, Sig i
Ms, AuthP athi
Mstogether with the signature counter iand
the current validation key V Kn−i
Msto an intended mobile device Mv.
Signature Verification. The mobile device Mvproceeds the followings to check
the status of the mobile device Ms:
–Obtains CertMsand queries whether the status of CertMsis valid or not.
–Verifies the current validation key based on the root validation key in the obtained
certificate, i.e., hi(V Kn−i
Ms)?
=V Kn
Ms.
–If all the checks are successful, the mobile device Mvcaches CertMsand sets the
current local time as starting trust time and the ending trust time based on the
control window in CertMs.
To verify the received signature, the mobile device Mvperforms as follows:
–Calculates a message digest md0=h(m) and sets C0= number of ’0’-bits in md0,
and then sets msg0=md0||C0.
–Sets Sig0
Ms=SigMsby denoting Sig0
Ms={sig0
j}t
j=1, where t=|msg0|and
updates sig0
j←− h(sig0
j),∀j∈ {j|msg0
j= 1}, and then calculates P LCi
Ms=
{sig0
1|···|sig0
t}.
–Iteratively hashes P LCi
Mswith AuthP athi
Msand compares the result to P KMsin
the certificate CertMs.
In comparison with previously proposed server-assisted computation approaches
[1][2] to reduce computational overheads on resource-constrained mobile devices,
the proposed protocol does not need to perform any public key operations and
employ any signature server at all.
Also, the verifier needs not to query the signer’s certificate status informa-
tion to the personal CA during the period of control window since the verifier
trusts the signer’s certificate based on the hash chain in the certificate up to
the ending trust point. As a result, our protocol provides moderate communi-
cation and computational overheads for validating certificate status compared
with OCSP[11] and CRLs[4].
5 Evaluations
In this section, we give evaluations of the proposed protocol in terms of the se-
curity and performance points of view.
Security Evaluations. To provide secure operations, it is necessary to prove the
security of both one-time signature scheme and control window mechanism used
in the proposed protocols. Clearly, we require that message digest hash function
h() is collision-resistant. Then, it is sufficient that: if the one-way hash function
h() used for committing secrets and hash operations in the Merkle’s one-time sig-
nature scheme is a collision-resistant function which implies preimage-resistant,
no signature for a message m06=mcan be forged.
Regarding the security of control window mechanism, it is obvious that: to
forge the mobile device’s current validation key corresponding to the i-th one-
time signature, an adversary should compute on his own the (n−i)-th h()-inverse
of the root validation key V Knin the mobile device’s certificate, which is com-
putationally infeasible work.
Performance Evaluations. Firstly, we compare the proposed protocol with the
most efficient server-assisted computation approach[1] in terms of computational
and storage requirements on system components. Note that computational re-
quirement of our protocol for signer is comparable with [1] without putting a
heavy burden on the server. Furthermore, signature verification of our protocol
is more efficient than [1] since verifier does not perform traditional signature
verification, but only needs to perform one-way hash computations. In particu-
lar, we solve the main problem in [1], which is the high storage requirement on
the server by removing the signature server. Recall server-assisted computation
approaches must store all signatures for resolving problematic disputes. In ad-
dition, considering storage requirement on the signer, our protocol only requires
1.9 KB approximately. (two 20 bytes security quantities and 1920 bytes hash tree
along with 4 bytes signature counter) while [1] requires about 3.3 KB (168 ∗20
bytes = 3.3 KB approximately.)
Upon taking into consideration of the efficiency of control window mech-
anism, clearly our protocol reduces the number of signature generations and
communication passes of the personal CA since the verifier does not query cer-
tificate status information to the personal CA during the period of control win-
dow. To have concrete and general measurements in terms of communication
costs, we consider the following parameters[10] to compare communication costs
with CRLs and OCSP:
–n: Estimated total number of certificates (n= 300,000).
–p: Estimated fraction of certificate that will be revoked prior to their expiration
(p= 0.1).
–q: Estimated number of certificate status queries issued per day (q= 300,000).
–T: Number of updates per day (T= 2, the periodic update occurs per 12 hours).
–C: Size of control window in our protocol (C= 2, the length of control window is
two days).
–lsn : Number of bits needed to hold a certificate serial number (lsn = 20).
–lsig, lhash : Length of signature and hash value (lsig = 1,024,lhash = 160).
Table 1. gives the estimated daily communication costs according to three certifi-
cate status management schemes. If we make use of control window mechanism
instead of OCSP, then communication cost for certificate status management
can be diminished by 65%.
6 Conclusion
In this paper, we have proposed an efficient protocol to reduce a burden of com-
putation for digital signature generation and verification on the PAN compo-
nents, and simplify the procedure of certificate status management in the PAN.
Compared with sever-assisted computation approaches, the proposed protocol
does not require performing any public key operations at all without assistances
Table 1. Comparisons of Daily Communication Costs
Scheme Communication Cost (bits)
CRLs 1.803 ×1011
OCSP 3.132 ×108
Our Proposal 2.046 ×108
CRLs daily cost: T·(p·n·lsn +lsig) + q·(p·n·lsn +lsig )
OCSP daily cost: q·lsn +q·lsig
Our protocol daily cost: q·lsn
C+q·lsig
C+q·lhash
of a signature server. Based on hash chain technique, and further, the proposed
protocol alleviates communication and computational costs for checking certifi-
cate status information.
References
1. K. Bicakci and N. Baykal, ”Server assisted signature revisited,” Topics in Cryptol-
ogy - CT-RSA 2003, pp.143-156 March 2003.
2. X. Ding, D. Mazzocchi and G. Tsudik, ”Experimenting with Server-Aided Sig-
natures,” 2002 Network and Distributed Systems Security Symposium (NDSS’02),
February 2002.
3. C. Gehrmann, K. Nyberg and C. Mitchell, ”The personal CA - PKI for a Personal
Area Network,” Proceedings - IST Mobile &Wireless Communications Summit
2002, June 2002.
4. R. Housley, W. Ford, W. Polk and D. Solo, ”Internet X.509 public key infrastruc-
ture certificate and CRL profile,” RFC 2459, January 1999.
5. M. Jakobsson, F. Leighton, S. Micali and M. Szydlo, ”Fractal Merkel tree repre-
sentation and traversal,” Topics in Cryptology - CT-RSA 2003, pp.314-326, 2003.
6. L. Lamport, ”Password authentication with insecure communication,” Communi-
cations of the ACM, 24(11), 1981.
7. R. C. Merkle, ”A digital signatures based on a conventional encryption function,”
Advances in Cryptology - CRYPTO’87, pp.369-378, 1987.
8. R. C. Merkle, ”A certified digital signature,” Advances in Cryptology -
CRYPTO’89, pp.218-238, 1989
9. D. Naor, A. Shenhav and A. Wool, ”One-Time Signature Revisited: Have They
Become Practical?,” Cryptology ePrint Archive, Report 2005/442, 2005.
10. M. Naor and K. Nissim, ”Certificate revocation and certificate update,” The 7th
USENIX Security Symposium, January 1998.
11. M. Myers, R. Ankney, A. Malpani, S. Galperin and C. Adams, ”X.509 Internet
public key infrastructure on-line certificate status protocol (OCSP),” RFC 2560,
June 1999.
12. F. Stajano and R. Anderson, ”The resurrecting duckling: security issues for ad-
hoc wireless networks,” The 7th International Workshop on Security Protocols,
pp.172-194, 1999.
13. J. Zhou, F. Fao and R. Deng, ”An Efficient Public-Key Framework,” The 5th
International Conference on Information and Communications Security, pp.88-99,
October 2003.
