Ethereum-Blockchain-Based

Technology of Decentralized
Smart Contract Certificate System
Rui Xie, Yuhui Wang, Mingzhou Tan, Wei Zhu, Zhongjie Yang, Jiaji Wu, and Gwanggil Jeon

Abstract
Traditional paper certificates and electronic certificates have difficulties in preservation and management, not to mention other
problems concerning inconvenient verification, poor reliability, anti-counterfeiting and anti-tampering. This paper proposes a scheme
designed to build a decentralized certificate system that is based on blockchain technology and smart contract, in which a set of
blockchain certificate system aiming at providing blockchain certificate services for college students’ innovation and entrepreneur-
ship competition is developed. In this system, certain functions of the certificate about management, issuing, verification and revoca-
tion are realized via smart contract. Signer information, certificate template and certificate information are stored in a smart contract
that adopts structured data, thereby realizing more convenient callings in querying and validating certificate.

Introduction This article proposes a decentralized system based on block-

chain technology, which makes possible certificate sharing
Certificates in earlier eras were paper made, they needed to be while enabling thorough trust among certificate receiver, cor-
designed and produced by issuing agencies within the issuing responding issuing authority and end users who will verify the
process, at a time certificate holders’ personal information was certificate validation by adopting smart contract without any
needed to finish issuing. After the holders obtained their certif- other systems.
icates, which had to be stored on their own, these certificates
needed to be shown when necessary. Paper certificates are so Related Works
inconvenient that due limitations owed emergence to difficul- Based on the bitcoin network, the MIT Media Lab Learning
ties in preservation, verification, and in anti-counterfeiting. Initiative, together with Learning Machine, proposed the Block-
As the IT industry develops, certificates change from printed Cert research project [8]. The project performed hash opera-
to electronic. Electronic certificates enable electronic equip- tion on the certificate data that accords with the Open Badges
ment storing, thereby providing corresponding applications and [22] format, which is provided by the issuing agencies. Then, by
interfaces to facilitate previously required issuance, query and initiating the transaction, the Hash value computed based on
verification, which greatly reduces inconvenience in certificate certificate data is stored in a bitcoin transaction data together
use, as well as the cost of issuance, management and preser- with a simple bitcoin script which is used for checking. Verifica-
vation. tion re-performed Hash operation on the certificate information
However, since electronic certificates are issued by certif- provided, and the calculated value, through bitcoin script, was
icate agencies independently, the following factors must be compared with the value that is stored in bitcoin transaction,
taken account into. First, certificate verification is realized by thereby verifying the authenticity of the certificate.
the agencies that store certificate information within their data- In 2018, the project LLP (Blockchain for Education: Lifelong
base providing applications and interfaces, under which may be Learning Passport) [9] was proposed by Gräther, Wolfgang
attacked and/or tampered by hackers, thereby voiding certifi- and some others, in which IPFS [23] was introduced as the per-
cates [1, 2]. Second, the data stored in the agencies’ database sistent storage of the certificate receiver’s information, thereby
would have voided and lose its accessibility if the agencies adopting a centralized document management system to store
disappear for certain reasons. Third, more difficulties will occur all the certificate information, as well as using smart contract to
when applications or interfaces are hard to be verified that record and verify the authenticity of the certificate.
whether the verification tool is provided by the agencies [3]. Moreover, Clemens and Brunner proposed a project named
Fourth, it is inconvenient and inefficient to verify certificates, SPROOF (a platform for issuing and verifying documents in a
because few verification tools provided are shared by various public blockchain) [10], using HD Wallet to enable better opti-
agencies, among which end users have to shift from one tool mized key security, store certificate information in DHT (Distrib-
to another. uted Hash Table) [11], and user privacy protection.
On January 3, 2009, the bitcoin network [4] was born,
simultaneously generating a new technology called blockchain. Problems
The very fundamentals of blockchain are new models of combi- There are three roles in certificate systems:
nation of applications, in which distributed data storage, point- 1. Roles of designing, issuing and managing certificates.
to-point transmission, consensus mechanism, and cryptographic 2. Roles of certificate acquisition and acceptance.
algorithm are embodied. Meanwhile, blockchain properties 3. Roles in need of verifying certificates, which can be further
of decentralization, anti-tampering and traceability are char- categorized into four types, thus requiring different functions
acterized by the above technologies. Based on decentralized of the system.
blockchain [6, 7], Ethereum [5] was proposed to realize pro- The first type are the roles of designing, issuing and managing
grammable smart contracts at the end of 2013, which makes certificates who is responsible for the designing of certificates
possible building a easy-verifying, anti-tampering, anti-counter- according to the real situation in granting certificates. The sec-
feiting and decentralized certificate system. ond type is the administrative role. Unauthorized certificate
issuing will cause chaos in the real world, in which distinguish-
Digital Object Identifier: 10.1109/IOTM.0001.1900094 ing issuers becomes impossible. On the contrary, the admin-

44 2576-3180/20/$25.00 © 2020 IEEE IEEE Internet of Things Magazine • June 2020

Authorized licensed use limited to: University of Glasgow. Downloaded on June 30,2020 at 07:32:12 UTC from IEEE Xplore. Restrictions apply.
 Field Description when deploying. This mode divides the participants of certifi-
cate authority into system managers, certificate issuing agen-
id Uuid of agency cies and certificate issuers, in which the managers deal with
the authority of certificate issuing agencies, while the agencies
name Name of agency
handle the authority of the corresponding issuers. Yet, the non-
pubkey Ethereum address of agency three-level mode classifies the participants of certificate author-
ity into certificate issuing agencies and certificate issuers, in this
authaddress Ethereum address of who authorize this agency mode, certificate issuing agencies can directly issue certificates
sign Signature based on their own demands without requiring the system man-
agers’ administration, while certificate issuers’ authority need to
Table 1. Data fields for certification authority. be managed under scrutiny by certificate issuing agencies.
Certificate data is stored in independent smart contracts,
through which the relevant data is accessed when it is issued,
Field Description verified, and revoked. Any access to the data will be checked
id Uuid of certifier by authorities; only users with corresponding permissions can
access the data by calling the certificate management contract,
name Name of certifier and the smart contracts storing the data can only be operated
by the certificate management contract.
pubkey Public key of certifier
The whole system does not rely on any third-party system
agencyid Id of agency which this certifier works for other than blockchain smart contract. The system provides cer-
tificate export for external data interface. The format of export
state State of certifier, valid or invalid data is compatible with version 2.0 of the Open Badges proto-
sign Signature col mentioned in the BlockCert project with due modifications,
improving system convenience, designing optional graphical
Table 2. Data fields for certificate issuer. tools, as well as facilitating user friendliness.
By adopting the smart contract language called Solidity, the
istrative role contributes to coordinating works that by whom system is developed on the version of Ethereum permissioned
or by which organizations these certificates are designed and blockchain, which shows no difference against direct implemen-
issued, thereby tracking system status and eliminating chaos. tation on the Ethereum.
The third type is the role of certificate acquisition and accep-
tance. Certificate issuance needs to be delivered to a designat- Smart Contract Based Certificate Data Model
ed person, organization or institution. A certificate is meaningful According to the characteristics of blockchain storage, we pro-
only when it is been acquired and accepted. The fourth role pose a protocol that conforms to the blockchain smart con-
type is certificate verifier. The certificate is regarded as an inter- tract storage, a temporary calling named Open Certificates, of
medium proving to people that the receiver has accomplished which is used to standardize the certificate information, thereby
something or has met certain qualifications. After being issued, facilitating data compatibility between different systems. In the
certificates need to be seen, recognized, and/or to be proven, protocol, only the key information of the certificate is kept,
in which the role of certificate verifier is performed and real- and the certificate data is categorized into issuing agencies
ized. To fulfill different various requirements, certificate systems data, issuer data, certificate template data, receiver data and
demand feasible and authentic administration, providing com- certificate data. The public key is to map the 32-byte private
plete information while preventing certificates from being coun- key to 65 bytes by adopting the elliptic curve ecdsa-secp256k1
terfeited and tampered, thus realizing convenience within its [14, 15] algorithm, while ultimately determining the relationship
issuing, verifying and managing process. Moreover, the system’s between public key and private key through the cryptography
adequate independence and reliability owe its priority above algorithm. Hence, all the data in this system are scrutinized by
other critical factors. the public key contained in the data for signature verifications,
BlockCert solves certificate issuing and verifying problems thereby examining whether the certificate data is modified [16].
via blockchain, whereas LLP solves certificate issuing, verifying The certification authority data shown in Table 1 is applied
and data storing problems by introducing a centralized docu- by the certification authority in the three-level authority mode
ment management system and DHT storage matching smart and is accordingly added to the blockchain by the system man-
contract. By implementing cryptographic algorithms, the bitcoin ager. The data contains information concerning the issuing
network and DHT storages, SPROOF solves certificate issuing, authority, the key pair applied by the authority, and the key pair
verifying and data storing problems. While the above methods used by the system manager who added the authority’s infor-
partly meet the certificate system’s requirement, despite solv- mation; the data signature is also stored in the corresponding
ing certificate counterfeiting and tampering problems to some data simultaneously. In non-three-level mode, the certificate
extent, there exists no effective method that solves all potential issuing authority can submit the data to the blockchain on its
difficulties and problems in certificate systems. own.
To meet the requirements in both certificate systems and in Certificate issuer data is supervised by the certificate issuing
reality, this article proposes a decentralized certificate system authorities. According to its own operation demands, the certifi-
based on blockchain technology and smart contract, providing cate issuer adds and manages the certificate issuer, in which the
a novel perspective for issuing, verifying and managing certifi- data includes the issuer information, issuer public key, and the
cates, which makes possible blockchain digital certificates shar- issuing authority that adds the data and the signature of issuer
ing while enabling thorough trust between certificate receiver status and data. Table 2 shows the data of a certificate issuer.
and corresponding issuing authority. In practice, countless certificate copies of the same kind
are given to different certificate receivers. For example, within
Overview in System Designing this year, 120 college students from the School of Computer
This system adopts smart contract to realize authority manage- Science and Technology in a university will receive their degree
ment, certificate issuing, certificate verification and certificate certificates issued by the university upon graduation, among
revocation. Authority management is structured as a three-lev- which the information merely differ in various individual names.
el adjustable mode, in which the contract deployer decides At the same time, certain certificate receivers accept various
whether to adopt three-level or non-three-level authority mode certificates. For example, as a record breaker of Guinness

IEEE Internet of Things Magazine • June 2020 45

Authorized licensed use limited to: University of Glasgow. Downloaded on June 30,2020 at 07:32:12 UTC from IEEE Xplore. Restrictions apply.
 Field Description certificates’ information differs. Therefore, we divide and further
categorize the certificate information into three types, certifi-
id Uuid of certificate template cate template information, certificate receiver information and
certificate information.
name Name of certificate
In a certificate, the certificate template information records
narrative Detail information and criteria of certificate all the general information other than receiver information. The
certificate receiver information focuses on the personal data of
certified Id of certifier the certificate receiver. The certificate information records the
sign Signature issuing date and the certificate issuer, associating the adopted
template with recipient information. When multiple copies of a
Table 3. Data fields for certificate template. certificate need to be issued in this way, only the relational data
between the template and the recipient is added, which greatly
Field Description improves the efficiency in data storage and in processing. In
Table 3, the template data that matches the paper certificate
id Uuid of the certificate receiver information is designed and filled by the issuer, which contains
recipient Name of receiver
the template name, certificate details, the issuer who generated
the template, and the signature of the template data.
identity Hash value of the identity of receiver The receiver information displayed on the paper certificate is
public. In this system, the corresponding information is designed
certified Id of certifier as independent data, in which only the receiver names and user
sign Signature identities are preserved. It only needs to retain the recipient’s
name and user’s identities. The user identity performs the Hash
Table 4. Data fields for certificate receiver. value by calculating the receivers’ identity information, there-
by ensuring the irreversibility of Hash query. Only when the
Field Description certificate receiver provides the identity information can hash
comparison be performed, thus enabling the protection for user
templateid Id of certificate template
privacy [17, 18]. In Table 4, the certificate receiver data is filled
recipientid id of receiver in by the issuing authority and can only be added instead of
being modified. The receiver data contains the name, the Hash
issueon Issue date of certificate value calculated from the identity information, the issuer infor-
expiredate Expire date of certificate (optional) mation and the data signature.
In Table 5, certificate data is generated by the issuer with
certifierid Id of certifier regard to certain factors concerning template, receiver infor-
mation and issuing time, which is embodied with template ID,
sign Signature
receiver ID, issuing date, optional expiration date, issuer infor-
Table 5. Data fields for certificate. mation and data signature.
The public and private key pair of the user is generated
record, Ashrita Furman has broken more than 600 official Guin- throughout the cryptographic algorithm, which enjoys a unique
ness World Records, keeping 226 Guinness World Records correspondence relation and is adopted in the smart contract
until now, which means he owns more than 600 certificates to confirm the user’s identity and authority. By checking the
that share the same receiver information whereas the certifi- recorded certificate content and the public key used for signa-
cates’ information differs. Therefore, we divide and further cat- ture, we can scrutinize whether the certificate data is fabricated
egorize the certificate information into three types, certificate or tampered [19, 20].
template information, certificate receiver information and certif- In this system, all the data is stored in smart contracts and
icate information. In a certificate, the certificate template infor- can only be accessed through the data management contract
mation records all the general information other than receiver named CertManage Contract. The caller’s permissions are
information. The certificate receiver information focuses on the checked against their address to guarantee that only the issuing
personal data of the certificate receiver. The certificate infor- authority adds a new issuer within its agency, thereby further
mation records the issuing date and the certificate issuer, asso- ensuring that only authorized issuers add templates, issue and
ciating the adopted template with recipient information. When revoke certificates within their agency.
multiple copies of the certificate need to be issued in this way, The issuing authority data is stored in the CertAgency Con-
only the relational data between the template and the recipient tract, the issuer data is stored in the Certifier Contract, the tem-
is added, which greatly improves the efficiency in data storage plate data is stored in CertTemplate Contract, the receiver data
and in processing. In Table 3, the template data that matches is stored in the Receiver Contract, and the certificate informa-
the paper certificate information is designed and filled by the tion is stored in the Certificates Contract.
issuer, which contains the template name, certificate details,
the issuer who generated the template, and the signature of the Authority Management for Three-Level Sysytem
template data. In the three-level system authority management, the system
In practice, countless certificate copies of the same kind manager, the certificate issuing agency and the issuer have
are given to different certificate receivers. For example, within different authorities and access methods. The manager can
this year, 120 college students from the School of Comput- be selected by forming an alliance committee or by the smart
er Science and Technology in a university will receive their contract deployer. In the process of adding a certificate issuing
degree certificates issued by the university upon graduation, agency, the certificate issuing agency first provides the system
among which the information merely differs in various indi- manager with the agency information and the public key it
vidual names. At the same time, certain certificate receivers uses, then the system manager reviews and verifies the authen-
accept various certificates. For example, as a record breaker ticity and qualification of the certificate issuing agency applying
of Guinness record, Ashrita Furman has broken more than 600 for registration. After the approval, the certificate issuing agency
official Guinness World Records, keeping 226 Guinness World can implement routine operations within the system.
Records until now, which means he owns more than 600 cer- The information of the certificate issuing agency and the
tificates that share the same receiver information whereas the public key it uses are stored in the CertAgency Contract. Add-

46 IEEE Internet of Things Magazine • June 2020

Authorized licensed use limited to: University of Glasgow. Downloaded on June 30,2020 at 07:32:12 UTC from IEEE Xplore. Restrictions apply.
 Subsequent management operations of the certificate issuer
Ce r t if ica t e
Ag e n cy
Ad m in is t r a t or / c) Ch e ck on the certificate will undergo throughout the permission check
Com m it t e e
by CertManage Contract.
P e r m is s io n

a ) A p p ly b ) S u b m it
Da t a
d ) W r it e After being authorized successfully, the certificate issuer
Ce r t Ma n a g e Ce r t Ag e n cy
can add or revoke certificates, and the relevant operations will
Con t r a ct Con t r a ct
be checked by CertManage Contract, in which any certificates
B lock cha in cannot be operated without permission.

Figure 1. The workflow of adding agency through smart contract. the realIZatIon of
certIfIcate management vIa smart contract
The certificate issuer calls CertManage Contract, adding a tem-
Cer t if ica t e plate in CertTemplate Contract. When issuing a certificate, the
A g ency b ) Ch e ck
Ce r t Ag e n cy
issuer chooses the suitable template, fills in the receiver infor-
c) Ch e ck Con t r a ct
P e r m is s io n
P e r m is s io n mation, and signs the information. After signing, CertManage
a) Ad d Ce r t i f i e r Contract will write the relevant data into the Certifier Contract.
I s s uer Con t r a ct
If the receiver does not exist, its information will be added into
Ce r t Ma n a g e
Con t r a ct
d ) W r it e
the Receiver Contract.
The specific procedure of certificate issuance is shown in
B lochcha in Fig. 3:
• Certificate issuer gathers receiver information.
• Submit information of the certificate being issued by calling
Figure 2. The workflow of adding issuer through smart contract. CertManage Contract.
• Check permission through CertManage Contract.
ing data can only be operated by the system manager through • Call the Certifier Contract to check the issuing authority.
the CertManage Contract. The process of adding its authority is • Call the CertAgency Contract to check the current issuing
shown in Fig. 1: authority.
• The certificate issuing agency submits its application to the • Call the CertTemplate Contract.
system administrator or certificate alliance committee. • Call the Receiver Contract to check receiver.
• The system administrator or the certificate alliance committee • Write the certificate information into Certifier Contract after
calls CertManage Contract to submit both the certificate passing all checks.
agency’s public key and its information. • Give feedback of the certificate issuing result to the issuer.
• CertManage Contract checks whether the caller’s permission • The issuer informs the receiver of the issued certificate infor-
conforms to the management permission. mation.
• After the check is passed, the issuing agency data is written The certificate receiver obtains from the issuer its own certifi-
into CertAgency Contract. cate which includes number, hash value, name, issuing date and
Under the non-three-level authority mode, the certificate receiver information.
issuing agency can register itself as the issuer in the contract The certificate receiver provides the certificate information
by calling CertManage contract without the system manager’s to the person or institution who needs to verify the certificate
permission. if necessary. By calling the smart contract or adopting the tools
After being authorized successfully, the certificate issuing provided, the certificate verifier performs its verification.
agency can use its private key to call CertManage Contract to Figure 4 shows the smart contract algorithm in verifying
register its own staff’s information and its public key information certificate information, which can be divided into seven steps:
into Certifier Contract, making its staff become the certificate • Call the smart contract, retrieve data of the entered Certifi-
issuer by setting its authority. cate to check whether the certificate is in the blockchain; if
The procedure of adding a certificate issuer to the smart so, proceed to next verification.
contract is shown in Fig. 2: • If the certificate can be found in the blockchain, the certif-
• Submit certificate issuer data. icate information is checked by the smart contract. If the
• Check the corresponding calling permission. calculated signature is consistent with the existing signature,
• Check the caller’s authority via CertAgency Contract. proceed to next verification.
• Write the issuer data into Certifier Contract after the permis- • If the certificate signature checking is passed, the public key
sion check is passed. corresponding to the signature, the public key used by the

d ) Ch e ck e ) Ch e ck
Receiv er I s s u er P e r m is s io n P e r m is s io n
a ) S u b m it
Ce r t if ie r
Co n t r a ct

f ) Fe t ch
b ) S ig n in g r e q u e s t T e m p la t e Ce r t T e m p la t e Ce r t A g e n cy
Co n t r a ct Co n t r a ct
i) Re t r u n r e s u lt
g ) P r o ce s s
Ce r t Ma n a g e c) Ch e ck Re ce iv e r
Co n t r a ct P e r m is s io n
j) No t if y Ce r t
Ce r t if ica t e s Re ce iv e r
Co n t r a ct Co n t r a ct
h ) W r it e

B lock cha in

Figure 3. The workflow of issuing certificate through smart contract.

IEEE Internet of Things Magazine • June 2020 47

Authorized licensed use limited to: University of Glasgow. Downloaded on June 30,2020 at 07:32:12 UTC from IEEE Xplore. Restrictions apply.
 PROCEDURE VERIFY(certificatehash)
certificate <- Get from Certificate Contract according to certificatehash f ) Ma r k a s r e v o k e d
Ce r t if ica t e
IF certificate NOT EXIST THEN Ag e n cy
RETURN FALSE b ) Ch e ck
P e r m is s io n
Ce r t i f i e r
Con t r a ct
c) Ch e ck
template <- Get from CertTemplate Contract according to certificate.certid a ) Re v o k e
P e r m is s io n
g ) Ma r k a s r e v o k e d
IF template NOT EXIST THEN Ce r t if ica t e
d ) Ch e ck
RETURN FALSE Issuer Ce r t Ma n a g e
Con t r a ct
P e r m is s io n

recipient <- Get from Receiver Contract according to certificate.recipientid

IF recipient NOT EXIST THEN e ) S e a r ch Ce r t Ag e n cy
Con t r a ct
RETURN FALSE Ce r t if ica t e
Ce r t i f i ca t e s
issuer <- Get from Certifier Contract according to certificate.issuerid Con t r a ct

IF issuer NOT EXIST THEN

RETURN FALSE B lock cha in
agency <- Get from CertAgency Contract according to issuer.agencyid
Figure 5. The workflow of revoking certificate through smart
IF agency NOT EXIST THEN
contract.
RETURN FALSE
IF TRUE != check_signature(recipient.recipient, recipient.identity, recipient.sign,
issuer.pubkey) THEN
RETURN FALSE
Et hereum C h e ck
IF template.issuerid != issuer.uuid OR TRUE != check_signature(template.name, web 3 SDK P e r m is s io n
G U I To o l I n t e r a ct
template.narrative, template.sign, issuer.pubkey) THEN
C e r t M a na g e
RETURN FALSE C ont r a ct

IF TRUE != check_signature(certificate.certid, certificate.recipientid, Verify

Verify

certificate.issueon, certificate.expiredate, certificate.sign, issuer.pubkey) THEN Et hereum

B lo c k c ha in
web 3 SDK
RETURN FALSE W e b To o l
IF certificate.id IN issuer.revokelist or certificate.id IN agency.revokelist THEN
RETURN FALSE Figure 6. Demonstration of GUI tools.
authorityaddress <- Authority address is set by the contract deployer
authoritypubkey <- Authority public key is set by the contract deployer
IF agency.authaddress != authorityaddress OR TRUE != check_signature(agency.name,
agency.address, agency.sign, authoritypubkey) THEN cases In PractIce
RETURN FALSE Based on the above implementations, we develop a block-
IF issuer.state == FALSE or TRUE != check_signature(issuer.name, issuer.address, chain certificate system on the Ethereum permissioned block-
issuer.agencyid, issuer.sign, agency.pubkey) THEN chain, thereby providing the blockchain certificate service for
RETURN FALSE college students’ innovation and entrepreneurship compe-
nowdate <- Get the timestamp from transaction tition. The system’s function includes the authority manage-
IF issuer.expiredate < nowdate THEN ment of the certificate issuing agency and issuer, as well as
RETURN FALSE the function of certificate issuing, verification and revocation.
return TRUE Although users can directly access the smart contract to per-
Figure 4. Algorithm to verify certificate in smart contract.
form all system operations, certain graphical interface tools
are accordingly developed to provide better user-friendliness,
as is shown in Fig. 6. The Ethereum web3.js is built within the
template and the public key pair publicized by the issuer are tools, thereby realizing convenient certificate quick query,
checked; if they are all valid, proceed to next verification. verification and social sharing. Meanwhile, the developed
• Match the corresponding certificate issuer with the public small tools facilitate the process for calling smart contract that
key, check whether the issuer revokes the certificate; if not, performs permission and certificate batch management, as
proceed to next verification. shown in Fig. 7.
• Check whether the certificate issuer has been removed; if In this practice, the system provides interface-friendly design,
not, proceed to next verification. facilitating compatibility with other tools or systems. The data
• Check if the current certificate expires using the expiry date obtained by calling the smart contract is expressed in JSON
in the certificate; if not, proceed to next verification. format, which merely demands format changing to be easily
• Accomplish certificate verification and return the validation compatible with the other protocols.
result to the smart contract caller.
Once the certificate needs to be revoked due to certain dIscussIon
problems, the certificate can only be revoked by the issuer or We introduce two modes in this system designing, i.e., three-lev-
agency that issues the certificate. Records of certificate revo- el authority management and non-three-level authority manage-
cation will be kept in the issuer’s or issuing authority’s certif- ment, which can be respectively applied in the situation where
icate revocation list [21]. Expired status validation has been the authority management of the issuing agency is required,
performed during the certificate validation process, which is not and where the corresponding management is not required. In
included in the scope of revocation. practical application, smart contract is fully used to store and to
The certificate revocation process is shown in Fig. 5: manage certificates without relying on any third-party system,
• Call CertManage Contract, submit certificate hash value. which is completely decentralized and enjoys good reliability.
• Check caller permission. The information of the certificate receiver is not fully preserved,
• Check whether the caller has issuer permission. thereby eliminating information leakage of users’ privacy on the
• Check whether the caller has issuing agency permission. premise of guaranteeing the integrity of certificate information.
• Retrieve data of the certificate to be revoked. The protocol in this system is flexible, independent of certificate
• Write the certificate revocation record into the Certifier Con- control, of which moderate modification helps achieve general-
tract after passing the check. ized document storage.
• Write the certificate revocation record into the CertAgency Compared with BlockCert, LLP and SPROOF, the system
Contract. enjoys the following advantages, as shown in Table 6:

48 IEEE Internet of Things Magazine • June 2020

Authorized licensed use limited to: University of Glasgow. Downloaded on June 30,2020 at 07:32:12 UTC from IEEE Xplore. Restrictions apply.
 BlockCert LLP SPROOF This System

Smart contract No Partial No Yes

Permission
No Yes No Yes
management

Independency No No No Yes

Storage Third party Third party Third party Self-contained

Privacy protection Yes Yes Yes Yes

Full certificate
No No No Yes
information

Decentralization No No Yes Yes

Transparency Yes Yes Yes Yes

Completeness No No Yes Yes

Table 6. Distinctive features of Blockchain certificate system.

Our next step is to extend the smart contract to adopt new

authority management schema, to develop general processes
and to define the protocol for digital data storage in smart con-
Figure 7. Display of certificate information. tract for general purpose.
References
• Complete information. The system provides complete cer-
[1] S. A Brands, Rethinking Public Key Infrastructures and Digital Certificates: Build-
tificate information, preventing meaningless Hash values, ing in Privacy, MIT Press, 2000.
whereas not requiring the certificate issuer to provide a sys- [2] M. Chase and S. S. Chow, “Improving Privacy and Security in Multi-Authority
tem for user verification. Attribute-Based Encryption,” Computer and Communications Security, 2009,
• Authority separation. The system introduces the three-level pp. 121–30.
[3] D. Boneh et al., “A Method for Fast Revocation of Public Key Certificates and
authority mechanism of the manager, the issuing agency Security Capabilities,” USENIX Security Symp., 2001, pp. 22–22.
and the issuer. By revealing the public key information and [4] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008, https://
other information of the manager, the issuing agency and the bitcoin.org/en/bitcoin-paper, accessed Nov. 20, 2019.
issuer, the verifier can distinguish different issuers and issuing [5] V. Buterin, “Ethereum: A Next Generation Smart Contract & Decentralized
Application Platform,” https://github.com/ethereum/wiki/wiki/White-Paper,
agencies. accessed Nov. 20, 2019.
• High reliability. The system only adopts smart contract to [6] L. Luu et al., “Making Smart Contracts Smarter,” Computer and Communica-
solve the certificate system problems, neither does it rely on tions Security, 2016, pp. 254–69.
any third-party tools and systems, nor will it cause any prob- [7] K. Ohara, “Smart Contracts — Dumb Idea,” IEEE Internet Computing, vol. 22,
no. 2, 2017, pp. 97–101.
lems concerning verification cheating. As long as the block- [8] J. Nazaré and K. Hamilton, “Digital Certificates Project,” http://certificates.
chain network is running, the certificate can be verified. media.mit.edu/, accessed Nov. 20, 2019.
[9] W. Gräther et al., “Blockchain for Education: Lifelong Learning Passport,”
Conclusion and the Future https://dl.eusset.eu/handle/20.500.12015/3163, accessed Nov. 20, 2019.
[10] C. Brunner, K. Fabian, and E. Dominik, “SPROOF: A Platform for Issuing and
Compared with existing traditional certificate systems and other Verifying Documents in a Public Blockchain,” Int’l. Conf. Information Systems
blockchain solutions, the blockchain certificate system pro- Security, 2019, pp. 15–25.
posed in this article is a set of certificate system based on block- [11] P. Maymounkov and D. Mazieres, “Kademlia: A Peer-to-Peer Information
chain technology, which completely adopts the smart contract System Based on the XOR Metric,” Int’l. Wksp. Peer to Peer Systems, 2002,
pp. 53–65.
and does not rely on any other third-party system, and can [12] W. Cai et al., “Decentralized Applications: The Blockchain-Empowered Soft-
meet the requirements for practical applications, replace the ware System,” IEEE Access, 2018, pp. 53019–033.
existing traditional electronic certificate system, solve the prob- [13] C. Konstantinos and M. Devetsikiotis, “Blockchains and Smart Contracts for
lems that exist in the past blockchain certificate system, thereby the Internet of Things,” IEEE Access, 2016, pp. 2292–303.
[14] D. H. Johnson, A. Menezes, and S. A. Vanstone, “The Elliptic Curve Digital
further realizing practical application of the blockchain technol- Signature Algorithm (ECDSA),” Int’l. J. Information Security, vol.1, no. 1, 2001,
ogy within the field of education, which enjoys great guiding pp. 36–63.
significance in practice. [15] SECG, “SEC 2: Recommended Elliptic Curve Domain Parameters,” http://
The current system is only focused on certificates while the secg.org/sec2-v2.pdf, accessed Nov 20, 2019.
[16] A. Ezell and J. Bear, Degree Mills: The Billion-Dollar Industry That Has Sold
basic idea of adopting smart contract for role definition, author- over a Million Fake Diplomas, Prometheus Books, 2005.
ity management, data anti-tampering and privacy protection [17] G. Zyskind, O. Nathan, and A. Pentland, “Decentralizing Privacy: Using
can be used in other fields. In a traditional IoT system, typical Blockchain to Protect Personal Data,” IEEE Symp. Security and Privacy, 2015,
devices are facing problems of security vulnerabilities [24] while pp. 180–84.
[18] K. Ahmed, “Hawk: The Blockchain Model of Cryptography and Privacy-Pre-
the thought of authority management based on blockchain can serving Smart Contracts,” IEEE Symp. Security and Privacy, 2016, pp. 839–58.
be used to solve these problems. Also, the idea of using smart [19] R. L. Rivest, A. Shamir, and L. M. Adleman, “A Method for Obtaining Digital
contract and blockchain in this article can be used to secure Signatures and Public-Key Cryptosystems,” Commun. ACM, vol. 21, no. 2,
data transition [25], secure data storage, control data access 1978, pp. 120–26.
[20] R. C. Merkle, “A Certified Digital Signature,” Int’l. Cryptology Conf., 1989,
[26, 27] and protect privacy. pp. 218–38.
The potential issue we have is in three-level authority man- [21] M. Naor and K. Nissim, “Certificate Revocation and Certificate Update,” IEEE
agement, the system will be affected if the private key is lost or JSAC, vol. 18, no. 4, 2000, pp. 561–70.
compromised. There should be a voting schema in the authority [22] Open Badges, “Open Badges v2.0 IMS Final Release,” https://www.imsglob-
al.org/sites/default/files/Badges/OBv2p0Final/index.html, accessed Nov. 20,
management system to make decisions according to all attend- 2019.
ees’ opinions in this system to avoid the affect from that private [23] IPFS, “Peer-to-Peer Hypermedia Protocol,” https://ipfs.io, accessed Nov. 20,
key. 2019.

IEEE Internet of Things Magazine • June 2020 49

Authorized licensed use limited to: University of Glasgow. Downloaded on June 30,2020 at 07:32:12 UTC from IEEE Xplore. Restrictions apply.
[24] F. Meneghello et al., “IoT: Internet of Threats? A Survey of Practical Security Zhongjie Yang ([email protected]) is a co-founder and vice
Vulnerabilities in Real IoT Devices,” IEEE Internet of Things J., vol. 6, no. 5, president of Beijing Mobike Technology Co. Ltd. His focus
2019, pp. 8182–210. is on AI and IOT and mobile communication technology. He
[25] O. Bello and and S. Zeadally, “Intelligent Device-to-Device Communication developed the world’s first smart shared bicycle lock, and cre-
in the Internet of Things,” IEEE Systems J., vol. 10, no. 3, 2016, pp. 1172–82. ated the smart shared bicycle mode. He is a senior member of
[26] Y. Zhang et al., “Smart Contract-Based Access Control for the Internet of the China Electronics Society. He is an expert member of the
Things,” IEEE Internet of Things J., vol. 6, no. 2, 2019, pp. 1594–605. International Industry University Research Internet of Things
[27] O. Novo, “Blockchain Meets IoT: An Architecture for Scalable Access Man- Alliance. He graduated in communication engineering from
agement in IoT,” IEEE Internet of Things J., vol. 5, no. 2, 2018, pp. 1184–95. Xi’an University of Electronic Science and Technology. He is
[28] A. Zanella et al., “Internet of Things for Smart Cities,” IEEE Internet of Things a senior engineer and NPI project manager at Motorola Mobility Technologies
J., vol. 1, no. 1, 2014, pp. 22–32. China Ltd.

bIograPhIes Jiaji Wu ([email protected]) received the B.S. degree in

electrical engineering from Xidian University, Xi’an, China, in
Rui Xie ([email protected]) received the B.S. degree in 1996, the M.S. degree in astrometry and celestial mechanics
network engineering from Beijing University of Posts and Tele- from the National Time Service Center, Chinese Academy
communications, Beijing, China, in 2008. He is a co-founder of Sciences, in 2002, and the Ph.D. degree in electrical engi-
of Consensus Approach Co. Ltd. His current research is main- neering from Xidian University, Xi’an, China, in 2005. He is
ly focused on Blockchain technologies. currently a professor with Xidian University. His research inter-
ests include image processing, still image coding, hyperspec-
tral/multispectral image compression, communication, and
high-performance computing.

Gwanggil Jeon ([email protected]) received the B.S., M.S.,

Yuhui Wang ([email protected]) received a B.S. and Ph.D. (summa cum laude) degrees from the Department
degree in computer science from Beijing University of Posts of Electronics and Computer Engineering, Hanyang University,
and Telecommunications, Beijing, China, in 2005. He is the Seoul, Korea, in 2003, 2005, and 2008, respectively. He was
founder of Consensus Approach Co. Ltd. His current research with the School of Information Technology and Engineering,
is mainly focused on Blockchain technologies. University of Ottawa, Ottawa, ON, Canada, as a Post-Doc-
toral Fellow, from 2009 to 2011. He was with the Graduate
School of Science and Technology, Niigata University, Niigata,
Japan, as an assistant professor, from 2011 to 2012. He was a
prestigious visiting professor in the Dipartimento di Informatica, Università degli
Studi di Milano Statale, from 2019 to 2020. He is currently a professor at Xidian
Mingzhou Tan ([email protected]) is an expert in artifi- University, Xi’an, China and Incheon National University, Incheon, Korea. Dr. Jeon
cial intelligence, an adjunct professor at Xidian University, an was a recipient of the IEEE Chester Sall Award in 2007 and the ETRI Journal Paper
angel investor, the chief strategy officer of Turing Robot, an Award in 2008.
expert consultant for the People’s Network Research Institute,
and he served as the entrepreneurial mentor of several univer-
sities. Currently he is focusing on artificial intelligence, mobile
Internet technology, blockchain technology and IoT related
research work.

Wei Zhu ([email protected]) is a Master of Engineering and

a senior engineer. He is currently the Deputy Dean of the
School of Innovation and Entrepreneurship at Xidian Universi-
ty. He has long been engaged in innovation and entrepreneur-
ship in universities, mainly focusing on artificial intelligence,
Internet of Things, big data, intelligent hardware, mobile Inter-
net, cultural creativity and other fields. In the cultivation of
innovative entrepreneurship talents, entrepreneurship project
incubation, crowdfunding space and incubator construction
and operation, university scientific and technological achievements in terms of
transformation and cooperation between industry, university and research, he has
rich practical experience and strong theoretical research ability.

50 IEEE Internet of Things Magazine • June 2020

Authorized licensed use limited to: University of Glasgow. Downloaded on June 30,2020 at 07:32:12 UTC from IEEE Xplore. Restrictions apply.