FEATURE: SOFTWARE ARCHITECTURE

A Framework While evaluating potential applica-

tions of blockchains at CableLabs,
my colleagues and I developed a

for Determining framework for determining whether

blockchains are appropriate for a
system architecture.

Blockchain Our Methods

To gain insight on how applica-

Applicability
tion architectures might or might
not benefit from blockchains, we
performed a literature review, in-
terviews with companies using
blockchains for production products
Brian A. Scriber, CableLabs or services, and evaluations of 23
blockchain implementation projects
at CableLabs. We used the findings
// An analysis of 23 blockchain implementation to identify questions that might lead
projects provides the basis for a framework toward, or away from, using a block-
chain in a given problem space. We
that lets engineers, architects, investors, and codified these questions to create our
project leaders evaluate blockchain technology’s framework. (For more on the imple-
mentation projects, see the related
suitability for a given application. // sidebar.)

The Results
Evaluation of the 23 projects re-
sulted in the discovery of problems
that were ill-suited for blockchains.
It also helped us pare the list of
projects down to the few that
benefited from blockchains. The
decision to discontinue a block-
chain implementation occurred at
BLOCKCHAINS ARE A relatively who all check, confirm, and accept different stages in the development
nascent technology that has received the work of their cohort. The result lifecycle—mostly during planning
a fair amount of press and hype.1 is a distributed ledger of transac- or analysis, and sometimes during
They’ve also experienced consider- tions. (For more on what a block- design. The four implementations
able investment (for example, on chain is, see the related sidebar.) that reached the testing stage re-
the order of $1.4 billion for most This technology is being applied quired multiple significant pivots or
of 20162) and order-of-magnitude to an increasing range of industries redesigns.
growth over the past two years. and problem spaces. However, such This evaluation revealed 10 ar-
This technology groups transactions application might not always be ap- chitectural or blockchain charac-
into blocks, performs cryptographic propriate or optimal; in many cases, teristics that can help determine
work (typically hashing) to charac- a database and application logic blockchains’ appropriateness for an
terize a block’s contents, and links might be better. Blockchain inves- application. Along with the follow-
the blocks to create a chain. Such a tors, technologists, and architects are ing discussion of these character-
blockchain works in concert with looking for tools to help determine istics, I offer related questions for
other participants in the ecosystem this technology’s appropriate use. analyzing appropriateness.

70 I E E E S O F T WA R E | PUBLISHED BY THE IEEE COMPUTER SO CIE T Y 0 74 0 -74 5 9 / 1 8 / $ 3 3 . 0 0 © 2 0 1 8 I E E E

Immutability
Immutability is achieved through WHAT IS A BLOCKCHAIN?
cryptographic security and distri-
bution; this can be expensive. If
immutability isn’t critical for the For purposes of this article, a blockchain (also called a distributed ledger or a
architecture, blockchains might be cipher chain) is a distributed, ordered, back-linked list of blocks. Each block con-
relatively expensive compared to tains transactions that are hashed into a binary hash tree (also called a merkle
other persistence mechanisms (for tree), with the top of the tree (also called the merkle root) stored alongside the
example, databases). Determining transactions. Each block also contains the previous block’s hash, thus guaran-
the need for immutability is prob- teeing the chain’s integrity back to the first block (the genesis block).
ably the most important decision Blockchain distribution is coupled with trust creation and a consensus mech-
in the architectural process—will a anism for determining agreement on the next block to add. Without such distribu-
database accomplish it? tion and without a solution that provides Byzantine fault tolerance (resistance to
There are ways to cryptographi- detrimental actors), a blockchain would be no better than a file or database of
cally sign data, mechanisms to dis- transactions. Also, the trust created by the system would be limited to the trust
tribute data, and hashing technology available in that one file or database.
available to prove that data hasn’t
changed from its original form.
If the architecture’s goal to abso-
lutely ensure that actors in the eco-
system can’t change historical data, power, computation, backups, and participants). These limits can also
blockchains can provide persistence environmental controls. be audited and validated program-
without the update and delete func- matically through script execution
tionalities of databases and SQL. • Can a database accomplish this (assuming the blockchain enables
Keep in mind that blockchains have architecture’s design goals? that functionality).
no rollback problem; you simply live • Can user roles and restrictions in Architectures that already in-
with what has been committed to the database deliver the func- clude external systems, controls, or
the chain. tionality required? tracking might not benefit as much
Delivering the immutability nec- • Do the proof-of-work, from the visibility added by a block-
essary for a blockchain implementa- proof-of-stake, and consensus chain. However, when members of
tion will require mathematical effort. model align with the architec- an ecosystem complain about lack
In the Bitcoin model, SHA-256 tural and financial goals? of transparency, blockchains might
hashing serves as the foundation • Can node signing and shared be able to help provide assurance of
for the consensus model used to responsibilities accomplish the transparency.
converge on a single chain for all same goals as a complex consen-
blockchain participants. 3 (SHA sus model? • Does the architecture require
stands for Secure Hash Algorithm.) • What if a mistake is made and a transparency between actors?
Other architectures use algorithms correction is required? • Will the shared ledger require
such as scrypt, Skein, SHA-3, • What if there’s a desire to re- auditing?
or BLAKE for proof-of-work or move a record at some point? • Do the parties trust the transac-
proof-of-stake related to the con- tion recording, or do they use
sensus algorithm. There are real Visibility and Transparency external controls (for example,
costs associated with selecting In blockchains, all the participants escrow or notary services) to
the consensus algorithm and with can see the chain (even if other pro- help validate transactions?
voting for winning blocks (those tections exist for each transaction’s
agreed upon to be the foundation privacy or anonymity). This allows Trust
for the rest of the blockchain). for validation of contractual limits Blockchains don’t actually add
These costs are borne by the block- (for example, you’re allowed to sell trust to the equation; instead, they
chain participants and can involve a product to only n number of other can remove the need for trust from

J U LY/A U G U S T 2 0 1 8 | I E E E S O F T WA R E 71
 FEATURE: SOFTWARE ARCHITECTURE

medical environment, a pre-

THE IMPLEMENTATION scription needs a prescribing

PROJECTS physician),
• what was involved in a trans-
action (for example, which
Our evaluation of the 23 blockchain implementation projects explored sev- Internet-of-Things device re-
eral ecosystems and problem spaces. This included projects addressing col- quested a software update), or
laboration needs in healthcare, media distribution, network management, • how something moved through
distributed-denial-of-service mitigation, log file management, conditional execu- the workflow (for example, re-
tion of rules, Internet-of-Things registration, industrial workflow, manufactur- garding provenance or owner-
ing credential distribution, or privacy protection for commerce. Other areas of ship, who owned something last
study included blockchain technologies, current blockchain implementations, and who owned it previously).
public and private blockchains, and the beginnings of open source blockchain
implementations. In such situations, the key used to
There were strict time limitations on what we could explore. So, failing commit to the blockchain can be crit-
quickly would let us explore additional topics. Failure was defined by technical, ical, as can the public profile associ-
economic, or temporal hurdles, as well as the sponsor’s interest or acceptance ated with an identity. When identity
of the architecture as feasible for the problem space or the sponsor’s willingness is strongly coupled with the sign-
to fund additional phases of concept exploration. During the projects’ design and ing key (such as in those situations I
implementation stages, we took care to understand the design decisions, their just described), architects must con-
impact on the results, participants’ or interviewees’ concerns, and how dramati- sider the management of this pairing.
cally those concerns impacted the projects’ success or failure. When identity is extremely loosely
coupled, such as when it’s created
outside the blockchain architecture
an ecosystem or a central author- can help fundamentally change how (a la Bitcoin), the key alone can’t al-
ity. This ability is key to the correct participants interact and transact ways be used to correlate with an
application of these cryptographic business. individual’s or a machine’s identity.
primitives in a system, and it opens For complex workflows and However, care must be taken if that
the door for the removal of friction multiple-party collaborations, par- behavior is explicitly not desired.
in many economic environments. ticularly those with business pro- Those systems in which partici-
Comments such as “I need to be able cess trust issues,4 blockchains might pants and individual actors must be
to trust X.” or “How do I know it help. mapped specifically to their transac-
really happened?” indicate key op- tions can benefit from blockchains,
portunities to use blockchains. The • Does this architecture require which require signed transactions.
automation and publication of smart trust between independent In architectures in which anonymity
contracts enforces escrow behavior entities? is desired, anonymity can be accom-
that can satisfy the participating par- • Is there any entity or type of plished by not mapping signed trans-
ties’ trust concerns. These contracts transaction that stakeholders in actions to individuals. The real tests
establish the authority for represent- the ecosystem are willing to trust? are assurances that a transaction can’t
ing real-world events in electronic be counterfeited (or compromised) to
ledgers and execute the rules on the Identity appear as if it’s valid, that people can’t
basis of those events. Identity supports ecosystems in commit a transaction as if they were
If an ecosystem already has trust which there’s a requirement to know someone else, and that a transaction
established between participants, a the individual human or system in- will be recognized by others as pro-
blockchain might not deliver the de- volved in transactions. This might viding the basis for their decisions.
sired transformational change. How- involve knowing
ever, if the ecosystem lacks trust, • What are the potential roots of
using blockchains in collaboration • who or what performed a trust on which identity can be
with other application technologies transaction (for example, in the based?

72 I E E E S O F T WA R E | W W W. C O M P U T E R . O R G / S O F T W A R E | @ I E E E S O F T WA R E
 • What transaction elements are • Is the chain governed inside one Transactions that are linked to
important to associate (or dis- legal jurisdiction, or is gover- others, and particularly transactions
sociate) with identity: who com- nance spread across many? What that act upon others, might require
mitted a transaction, or what laws impact data persistence in scripting, which not all blockchain
activity was performed? each jurisdiction? implementations support. Scripting
allows for more-dynamic actions
Distribution Workflow during processing, including valida-
Distribution provides four key ben- Adding a blockchain to a system tion, verification, conditional logic,
efits that might be desirable for ar- that isn’t designed around a cen- execution or triggering of additional
chitectures for which blockchains tral ledger creates architectural transactions, and searching the
are being considered. The first is hurdles, specifically around work- blockchain. However, these capabili-
system reliability; if one node per- flow. If disparate systems have tra- ties add overhead, security consider-
ishes, the others continue to support ditionally worked directly with one ations, and rule management, and
the ecosystem. The second benefit another, adding an intermediary they increase the transaction storage
is that the security of the data en- backed by a blockchain adds fric- and the processing time for accept-
coded in the chain is assured by tion that can lead to issues (for ing a new transaction.
the cryptographic complexity and example, regarding performance, Some blockchain implementa-
proof-of-work provided by the par- communication, and data avail- tions rely on these scripts for secure
ticipants. The third is system integ- ability or protection). workflow execution; others can per-
rity and the ability to verify integrity Additionally, legacy systems and form the actions I just discussed,
through confirmation and consen- their interfaces require evalua- using an external workflow tool.
sus across the ecosystem. The fourth tion for fit regarding a blockchain, If the architecture under evalua-
is Byzantine fault tolerance (BFT), specifically for concerns with la- tion requires trusted scripting in the
which is a key driver for many or tency and transaction verification blockchain implementation, each
most blockchain architectures. 5 BFT requirements. Transaction verifica- consideration I’ve mentioned must
provides tolerance of (a minority of) tion might have been trusted to da- be addressed. It’s also important to
bad actors and participants who are tabases that could respond almost determine the ability of all the nodes
working to subvert an ecosystem. immediately if the transaction could to have visibility into the transaction
If your architecture can be managed be committed. Blockchains operate (unrestricted by encryption unless
without distribution, the costs of dis- under a more complicated acceptance they’re using homomorphic encryp-
tribution far outpace those of a system model. In a blockchain, a node might tion or zero-knowledge proofs7).
that can be contained in one node.6 accept a transaction, but it might
take an extended period of time • Do distributed ledgers help sim-
• What transaction cost does the (seconds to days, depending on the plify the workflow?
business case support? blockchain structure and consensus • Does the workflow require real-
• How many stakeholders are in model) for the transaction to be veri- time responses?
the ecosystem? fied, shared, accepted, and encoded • Do encryption schemes sup-
• Can each stakeholder or par- into the blockchain. port different nodes being able
ticipant run one of the nodes in So, the workflow must be evalu- to validate all transactions they
the ecosystem? Can participants ated for appropriate fit. Also, the ar- process, or does visibility restrict
share nodes? How are trust, chitecture must be able to support this?
verification of a submission’s ori- activities such as delayed rollback
gin, and voting handled between or cancellation of transactions by Transactions
nodes—specifically, shared the node after verification has com- As with workflow, if a system isn’t
nodes? pleted. If a blockchain doesn’t sim- transactional (for example, simula-
• Does the scale of distribution plify the workflow and doesn’t fit tion software), conversion to using
provide enough participants to well into the transactional seman- a blockchain might not be easy, and
achieve security, reliability, and tics, it might not be the best choice a blockchain might not be the best
availability goals? of architectural primitive. fit. Nontransactional systems would

J U LY/A U G U S T 2 0 1 8 | I E E E S O F T WA R E 73
 FEATURE: SOFTWARE ARCHITECTURE

need a conceptual bridge to adapt and concerns regarding records’ • Is it possible to revoke the cre-
to blockchains’ transactional model. longevity and immutability (as I dentials of parties involved in
That bridge would need to be able to discussed earlier). Although this per- the blockchain?
model interactions in the system as sistence is usually a primary reason • Incentives for participants might
transactions. If doing that is difficult for considering using a blockchain, change over time, and with a
conceptually, that difficulty will be the fact that the records are always historical collection of records or
amplified during development and available must also be a point of cau- transactions, additional concerns
maintenance. tion. If any artifacts of permanent arise. Although these concerns
Care needs to be taken in evalu- transaction availability (for example, are tangential, how will they be
ating what data will get encoded in personal information, even if en- addressed?
the blockchain and how it will be crypted) give pause in the architec- • Will each party continue to make
updated. This evaluation must take tural review, a blockchain might not be its chain available? How will you
into account that the data can’t be the ideal solution. The fact that the re- prevent a party from leaving,
removed (owing to storage costs) cords or transactions will be recorded quitting, or abandoning its sup-
and must envision how it could in the blockchain tie the concept of port for the chain, particularly if
be and would be accessed (which permanency to immutability. When the loss of this party could impact
the viability of distribution or the
economics of the ecosystem or
consensus mechanism? From the
Blockchains are a good fit for persistent-chain perspective, what
if, in the future, you desire to
ecosystems but not necessarily for shut down the chain and a party
single entities. denies this request and continues
to operate the chain and make the
data available?

Ecosystems versus Internal

involves privacy, persistence, and records in the chain are unchanging, or Installed Software
performance). the longevity of each transaction leads Blockchains are a good fit for eco-
Most blockchain implementations to these questions: systems but not necessarily for single
have been based on a transactional entities. This is because blockchains
exchange. Some projects lacking this • How are privacy concerns solve trust issues, and the presump-
feature have struggled with mapping handled? How will current and tion is that a single entity has other
the business need to the technology.8 future privacy concerns be pro- mechanisms for aligned strategy and
tected? Are the keys used to sign trust. In a single entity or a collab-
• Does the architecture require a and commit transactions long orative environment in which trust
series of transactions between enough to adequately protect already exists, architects can likely
independent parties, or is each the data? Do the cryptographic use other technologies for persis-
transaction atomic? components integrate forward tence, record-keeping, communica-
• If the workflow can’t be modeled secrecy into the protocol? What tion, and collaboration.
or diagrammed (for example, as if a record can be viewed in a
a state diagram or in Business manner not flattering to the • Will this software be part of a
Process Execution Language), transaction participants? collaborative ecosystem, or will
why and how will a blockchain • What if a court order requires it be used by a single entity?
be helpful? the removal of a record or trans- • Is the software an internal tool
action? Is compliance with such for a single company?
The Historical Record an order possible? Will such an • If the software is part of an eco-
Architects looking at blockchains order effectively mean destroy- system, do all participants have
need to evaluate the historical record ing the blockchain? an established trust model, or

74 I E E E S O F T WA R E | W W W. C O M P U T E R . O R G / S O F T W A R E | @ I E E E S O F T WA R E
 are there controls and systems the integrity of the cipher chaining. Discussion and
for verifying transactions and Similarly to how production data- Framework
actions? bases often aren’t used for reporting You can evaluate a blockchain’s level
• Are escrow practices in place? purposes, consider how caching and of fit for a particular purpose by as-
indexing older blocks in the block- signing weights to the 10 characteris-
Inefficiency chain might help improve perfor- tics we just discussed and multiplying
One concern with blockchain imple- mance when those blocks are still those weights by a subjective percent-
mentations is the actual blockchain’s important to the chain’s operations. age of affirmation for questions re-
inefficiency. This is closely related This is particularly the case for lated to the characteristics. Table 1
to immutability, distribution, and chains used in currency and smart- shows a form for such an evaluation;
workflow. This inefficiency comes contract environments. However, the questions summarize the salient
from three aspects of blockchain be aware of the security and integ- issues related to the characteristics.
architecture: rity issues of overrelying on cached A given implementation’s score
chains and the veracity of the data might be low or high; we designed
• the security framework and rigor stored therein. this tool primarily to help its users
required to operate the chain, perform a relativistic comparison
• the fact that blockchains use • How will data be used? Will of projects and carefully evaluate
a singly linked list as the data transactions need to be verified whether a blockchain is appropri-
structure, and in real time? ate for the ecosystem under consid-
• the transactional verification eration. The suggested weighting is
model associated with BFT. Byzantine fault tolerance. This last inef- based on our evaluations of the 23
ficiency comes from the need to implementations and lessons from
The security framework. Transac- other blockchain experiments.9 It’s
tions might need to be encrypted • distribute transactions, subjective and is intended only as a
or signed by the committing party. • competitively calculate blocks, guide; it might not apply to all envi-
This distributes well because in • commit those blocks for the con- ronments or evaluations.
many cases the client performs the sensus model to evaluate them, For four of the 23 implementations,
work. However, the architecture and then a blockchain seemed the best fit. The
here can be burdened by security- • collaboratively arrive on the ac- others, even when they were initially
related issues, particularly key cepted next block across the entire considered ideal for a blockchain, had
management, key security, device network of participating nodes. drawbacks during design or implemen-
power, and network access. For the tation. In those cases, a blockchain
IoT, some extremely constrained de- These tasks might be faster in
vices might be unable to perform smaller ecosystems than in globally • was too costly to support or ini-
more advanced cryptographic tech- distributed heterogeneous environ- tiate given ecosystem economics,
niques owing to limited bandwidth, ments. However, in either case, it’s • was too difficult to maintain suf-
battery capacity, memory, or pro- hard to make a consensus model ficient distribution, or
cessing power, or even heat man- that performs well and is fault tol- • encountered legal concerns that
agement issues. erant regarding bad actors. In an the ecosystem wasn’t ready to
environment in which immediate accept.
• Can the participants support the and irrevocable transactions are
required security? critical, conceptual maturation re- On the basis of our experience
garding this aspect of blockchains is with these implementations, we
The data structure. The necessary layout important. boiled down our questions to five
of a blockchain (a single backward- that seem fundamental for consid-
linked list or tree) means that add- • Will malicious actors be able eration of blockchain architectures
ing a block is intensive in its own to subvert the chain, or will the (see Table 2). Inadequate answers to
right. Navigation and search ef- consensus model be complex these questions might lead architects
ficiency are further sacrificed for enough to prevent this? to quickly consider other options.

J U LY/A U G U S T 2 0 1 8 | I E E E S O F T WA R E 75
 FEATURE: SOFTWARE ARCHITECTURE

Table 1. A form for evaluating a blockchain’s level of fit.

Weight (this Subjective
Example subjective column must add percentage of Weight 3
Architecture or blockchain characteristic suggested weighting up to 100) affirmation affirmation

Immutability: Will the architecture never need the ability to 12

execute a command with update or delete semantics?

Transparency: Does the architecture require transparency 12

between actors?

Trust: Does the ecosystem currently lack trust between 16

participants?

Identity: Must participants and actors be mapped to their 5

transactions, or do those transactions have a value to be
claimed by a participant?

Distribution: Can the implementation manage and afford 10

distribution of nodes and participants? Does the system have
multiple writers?

Workflow: Would the addition of a distributed ledger simplify 5

workflow?

Transactions: Does the system follow a transactional model, 12

or is the data transactional?

Historical record: Is the project ready to assume the fiscal, 8

legal, distributive, and cryptographic responsibilities of
running this chain for an indeterminate time period?

Ecosystem: Does the architecture support an ecosystem as 15

opposed to a single company?

Inefficiency: Will the architecture support a blockchain’s 5

security overhead, search limitations, and transactional
verification model?

Total percentage of fit:

A rchitects struggle to deter-

mine the best fit for their
projects, aiming for an
economic solution that simplifies
things instead of adding complexity.
both to help determine whether the
decision to use a blockchain is op-
portunistic rather than strategic and
to help refine solutions that are ap-
propriate for the problem space.
References
1. SWIFT on Distributed Ledger Tech-
nologies, SWIFT Research, 19 Apr.
2016; http://www.swift.com/insights
/white-papers.
In many cases, a blockchain’s com- 2. J. Kennedy, “$1.4bn Investment
plexities can overburden the solution Acknowledgments in Blockchain Start-Ups in Last 9
space. I hope that consideration of Special thanks to CableLabs; the Security Months, Says PwC Expert,” Silicon-
the criteria in this article will help ar- Team; and specifically Steve Goeringer, erepublic.com, 4 Nov. 2016; http://
chitects expedite decisions based on Zane Hintzman, Steven Saunders, Jim www.siliconrepublic.com/start-ups
experience and careful evaluation. Campanell, and Michael Glenn for their /blockchain-pwc-investment.
Investors and technical executives efforts on the blockchain implementation 3. A.M. Antonopoulos, Master-
can use the framework I presented projects. ing Bitcoin: Unlocking Digital

76 I E E E S O F T WA R E | W W W. C O M P U T E R . O R G / S O F T W A R E | @ I E E E S O F T WA R E
 Cryptocurrencies, O’Reilly Media,
2015. Table 2. Criteria for whether to choose blockchains.
4. I. Weber et al., “Untrusted Business
Question Considerations
Process Monitoring and Execution
Using Blockchain,” Business Process Will this project require updates, Blockchains are inherently permanent. If the architecture
Management, LNCS 9850, Springer, mutability, or deletion of records? requires anything other than rare additions of new blocks to
invalidate prior blocks, the overhead of checking for revocations
2016, pp. 329–347.
can have a significant negative impact in mature or large chains.
5. I. Eyal et al., “Bitcoin-NG: A Scalable
Blockchain Protocol,” Proc. 13th Is there agreement that all Distribution of blockchains and validation of transactions
USENIX Symp. Networked Systems blockchain participants should are critical. Without the use of obfuscating techniques that
be able to view and validate allow for transaction validation without viewing, the power of
(NSDI 16), 2016, pp. 45–59; http:// transaction details? distributed trust in the chain would be lost to the single node
www.usenix.org/system/files/conference that originally validated the transaction, which might not even
/nsdi16/nsdi16-paper-eyal.pdf. be a permanent member of the chain.
6. S. Davidson, P. De Filippi, and J.
Does this architecture fit well For internal projects in which significant trust already exists,
Potts, “Economics of Blockchain,” in an ecosystem of diverse a database solution will likely be far more economically
SSRN, 9 Mar. 2016; http://papers participants? appropriate.
.ssrn.com/sol3/papers.cfm?
Are there adequate incentives From the economic and technical perspectives, support for
abstract_id52744751. for participants to continue to the chain’s future depends on the maintenance of that chain
7. C. Fontaine and F. Galand, “A support the chain indefinitely? and storage of previous blocks (in many cases, active storage
Survey of Homomorphic Encryp- of all of them).
tion for Nonspecialists,” EURA-
From an efficiency perspective, Here, the economic and technical considerations collide when
SIP J. Information Security, 2007; are there enough participants you consider not only the long-term power, computation,
doi:10.1155/2007/13801. and sufficient complexity to buoy backup, maintenance, and support requirements but also the
8. M. Swan, Blockchain: Blueprint for the consensus model, validate changing landscape of adversarial engineering. Will the chain
all transactions, and approve the continually have enough positive influence in the consensus
a New Economy, O’Reilly Media,
authentication and authorization model to counteract negative actors and achieve Byzantine
2015. processes? fault tolerance?
9. X. Xu et al., “The Blockchain as a
Software Connector,” Proc. 13th
Working IEEE/IFIP Conf. Software
Architecture (WICSA 16), 2016; ABOUT THE AUTHOR
http://ieeexplore.ieee.org/document
/7516828.
BRIAN A. SCRIBER is a principal architect at CableLabs, focusing
on network security, blockchains, and cryptography. Scriber received
an MS in computer science from the University of Colorado, Colorado
Springs and an MBA from the University of Colorado, Boulder. He’s
the chair of the Open Connectivity Foundation’s Security Working
Read your subscriptions Group, focusing on Internet-of-Things security. He’s a member of IEEE.
through the myCS Contact him at [email protected] or @brianscriber.
publications portal at
http://mycs.computer.org

J U LY/A U G U S T 2 0 1 8 | I E E E S O F T WA R E 77