AUTHORED BY:

LIM HUCK HAI, BAKER TILLY MH CONSULTING SDN BHD

Digital ID Using a Trust Framework

INT

RO

A Trust Framework should consist of Technical and

Operational elements coupled with Legal Rules. It

is an evolutionary and not a revolutionary process

that is part of a journey that never ends.

A Trust Framework

A Trust Framework should consist of Technical and Operational elements coupled with Legal

Rules as follows:

Technical and Operation Specifications

• Enrolment (on-boarding)

• Identity Proofing

• Credential Issues

• Credential Management

• Privacy Standards

• Authentication Requirements

• Security Standards

• Audit

Legal Rules

• Regulate Technical and

Operational Specifications

• Make Technical and Operational

Specifications legally binding on

the participants

• Define and govern the legal rights

and responsibilities of the

participants

With the goal of achieving an acceptable Trust Framework that:

• Provides enforceable rules for a workable and trustworthy identity ecosystem that are

binding on all participants

• Adequately protects the rights of the parties

• Fairly allocates risk and responsibilities among the parties

• Provides legal certainty and predictability to the participants

• Complies with / works in conjunction with existing law

• Works cross-border (state or country)

1

The current public internet currently lacks the ability to obtain high levels of reliable identity

assurance. Furthermore, there is no mechanism to allow parties to be recognised and subsequently

authenticate each other.

Without this, organisations are exposed to higher levels of risk for anything other than low value,

high volume transactions. The physical world gives us guidance as to how technology ‘should’

behave so that they are more compatible with the needs of society and laws.

For instance, a Trust Framework needs to adopt a number of Design Principles, including:

• identification must be two way

• recognition must be two way and should not repeat the identification step

• authentication must be two way

• legal/regulatory obligations must be met

• choices must be available to both parties

• either party can refuse the terms and discontinue the relationship

• everything must be encrypted using keys which are created by and remain in the control of

the relevant parties

• every action must generate an audit trail entry and be auditable

• timestamps must be based on a reliable tamper-proof time source which is regularly and

independently audited

• the auditing function must not be capable of being disabled, be tamper resistant and evident

• naming must not be based on user IDs, email address, domains, etc.

• Pseudonyms are permitted, but only where explicitly declared

• No traffic may be passed over the trust framework that is not explicit and previously

authorised

Design Principle 2

Technical & Operational Specifications

3

1. Enrolment On-boarding is an increasingly onerous, expensive and risky process for any business, but particularly for regulated

businesses. Regulations such as KYC, Anti-Money Laundering and tax status require significant interaction with a

customer to ensure that the legal obligations are met and understood by the client. A compliant process avoids

fines from Regulatory bodies and/or reputational damage.

The TF enables clients to transform their on-boarding processes (by relationship type) with a number of benefits

accruing, including reduced cost of compliance, improved convince for the customer and more rigorous

enforcement of compliance policy.

The TF assists in the process by enabling the management of many factors, satisfying both legal and technical

security objectives. Enrolment onto the TF is achieved in two steps.

Step 1 - enrolment onto the TF itself,

Step 2 - enrolment of the client by the organisation by making use of the TF.

2. Identity Proofing A critical problem in cyberspace is knowing with whom one is interacting. Currently there are no ways to precisely

determine the identity of a person in digital space. Even though there are attributes associated to a person's

digital identity, these attributes or even identities can be changed, masked or discarded and new ones created.

Despite the fact that there are many authentication systems and digital identifiers that try to address these

problems, there is still a need for a unified and verifiable identification system. Thus, there are issues of privacy

and security related to digital identity.

3. Establishing a unique relationship T Any two parties using the TF require an explicit relationship between them to exist before any communication

can take place. The TF provides the tools to build new relationships, based on the requirements of the parties.

This is particularly useful for regulated businesses where compliances may rules requires multi-stage checks of

personal data, rules pertaining to a jurisdiction and regulatory environment, etc.

The agreed terms and rules between the parties are encapsulated in a Communications Agreement with a copy

retained by each party.

4. Identification The TF should adopt a legal view of identity, rather than a technical one. This means that the TF should provide

the parties with the ability to claim (and subsequently provide various assurances of) an identity.

6. Claim of Identity In law, an identity must be claimed by the individual or organisation - this ensures the liability for providing false

information remains with the claimant. Once an identity is claimed, it must be supportable by third party

‘references’ - this shows duty of care by the organisation, and increases trust.

The TF, via its intrinsic on-boarding features provides the tools required to ensure that claims of identity are always

supported by the necessary credentials before the person is capable of any interaction.

Note: should the status of a credential change, revoking or suspending the relationship with the person or

organisation is a simply and instant task, further improving how risk is

managed.

5. Supply of identity ‘proofs’ Identity ‘proofing’ is based on long established methods and accepts that there is no real proof, only levels of

assurance. The level of assurance provided is a risk-based assessment made by the relying party, based on the

quality of the supporting proofs (credentials) and quantity of proofs offered.

A TF should act as the facilitator, by providing the tools and processes for the relying party to receive identity

credentials from the claimant is a secure manner. The authenticity of the credentials may be further tested with

the original issuer of the credential. The relying party uses its own risk systems to make an assessment of the

credentials. This ensures that the burden of liability remains un-skewed and is not transferred to a third party with

no accountability.

7. Credential Issues A credential is a document or token that confers a right or privilege upon the recipient. In the simplest sense a

passport is a document that allows the bearer to travel under the protection of rules afforded by the issuer. It has

certain attributes, one of which is the identity of the bearer. In the context of electronic credentials, it is difficult

to bind the user to a credential because technology makes use of tokens. Tokens can be stolen, duplicated and

impersonated without the knowledge or recourse to the issuer.

There is no such thing as an electronic identity, only real identity. The TF manages the claim of real identity, backed

up by real credentials, either delivered electronically or referenced to the original issuer electronically. So if

someone claims an identity, provides the documentary evidence that supports their claim and the issuer of the

document agrees that the document and its contents are genuine, you have an identity upon which you can have

a degree of assurance that it is a genuine party.

8. Credential Management Organisations have technical vulnerabilities due to the way that IT systems tokenise the identity of users

(customers and staff). That is, technical credentials are issued as a proxy for real identity.

As such the credential management system becomes a critical attack vector. Anyone gaining control of the

credential management system can issue credentials that make them an insider, potentially with privileges to

compromise systems being undetected.

The re-issue of credentials following a system compromise, can be an expensive and time consuming process.

Broadly speaking, the 7 principles are:

1. Fair, lawful and transparent data processing - personal data must only be processed in this manner in relation to

the data subject

2. Limitation of purpose - personal data must only be collected for explicit and legitimate

purposes and not further processed

3. Data minimisation - personal data must be adequate, relevant and limited to what is

necessary for the data processing purpose

4. Data accuracy - personal data must be kept accurate, kept up to date and rectified without delay

5. Data retention periods - personal data must be retained for not longer than is necessary

6. Data security - personal data must be processed with appropriate security over unlawful processing, loss damage

or destruction.

7. Accountability - the data controller is responsible for adherence to Data Protection Principles and must

demonstrate compliance. The introduction of the General Data Protection Regulation (GDPR) in Europe legislation

is forcing organisations to examine what personal data they are processing (collecting), why they are collecting it

and have they made sure that the data subject has properly consented. This is further exacerbated by the fact that

many organisations collect personal data in different business tools often without reference to each other. A TF

solves this problem by creating a single source of business records and explicitly managing communication

channels by relationship type.

9. Privacy and Data Protection Standards Forthcoming Data Protection legislation is based around 7 principles and in some cases materially expands

upon the scope of existing data privacy rules.

10. Authentication Requirements Enterprises of all sizes have challenges in authenticating their staff, customers and suppliers, in fact anyone with

whom they have cause to communicate, and yet it is still only passively managed and largely lacking in control.

These requirements might take into account the location of the person at the present time, the device they choose

to use (is it a work laptop with a work-supplied authentication device as specified, or a BYOD device), or any other

measurable attribute.

11. Authentication policy Complex businesses have a variety of needs when interacting with various groups of people, In some cases they

have gone to great lengths to reach a decision on exactly how others can be identified, identity assurances can be

achieved and how they can subsequently be authenticated. In most cases, however, there is no method of binding

an authentication policy with implementation.

The TF requires that Authentication Policy is set before any use can be made of the framework. The organisation

may define its own policy by type of user (e.g. staff), so that standards can be met and enforcement is

demonstrably achieved.

The result is that high risk groups are required to go through additional authentication steps because it is

necessary, and lower risk groups do not have the same burden placed upon them. This is based on the judgement

and policy of the organisation and is not determined by the TF.

12. Confidentiality In information security, confidentiality is the property that information is not made available or disclosed to unauthorised

individuals, entities, or processes. In order to facilitate confidentiality information is normally encrypted so that only the

authorised individual (possessor of the encryption keys) is able to decrypt the information.

The architecture of the TF is a hybrid hierarchic/peer-to-peer model. The back-end systems of the trust framework provide

a national node for every participating country (and a method of navigating between them) and are required to provide

licensing control, directory services, presence, etc. These are used to manage authenticity of both users and their traffic.

All interaction between users (once a session is established) is on a peer-to-peer basis, in that it is not routed, not visible

to and not retained by the TF.

By adopting this mode, we can ensure and prove that information passed between the parties is confidential to them, and

remains so (in the context of the TF and its legitimate use).

13. Integrity Achieving any level of integrity on the public internet has become a significant challenge and this is a key driver for bringing

the TF to market.

In order to provide (and demonstrate) the level of integrity, end-to-end management of interactions is necessary, in a

similar way to managing the chain of custody of evidence in a criminal investigation would be managed.

The TF provides the means to track and trace every aspect of data integrity from identity, to role, authority to act, signing

and delivery. Further, the design of the TF ensures that every transaction is defined, managed and ultimately either reaches

its destination successfully, or is explicitly cancelled. There is no ‘fire and forget’ option.

14. Availability As business place a growing reliance on digital channels to conduct their business, and globalisation extends the business

day, availability of both the channels and the processes used to conduct business become more critical.

In reality, this means that the business should understand what their desired level of availability is, and this forms the basis

for architecting the local solution to deliver this.

Should a high level of availability be required, the TF organisation components can be clustered, replicated and load-

balanced to achieve the objective.

15. Asymmetric encryption of exchanged data Information exchanged with another party (in an explicit agreed relationship) is done using public keys generated locally

by the respective party. These keys are bound to the relationship. Keys are generated using the SHA-256 algorithm.

16. Exchange of public keys - Diffie-Hellman model Once a new relationship is established and the Communications Agreement has been created, a classic Diffie-Hellman

key exchange takes place, using the normal (encrypted) TF channels.

Key pairs are unique to the relationship, so in the unlikely event of a public key becoming compromised, the risk is limited

to a single relationship. The key pair would then be revoked and a new key pair issued. This is achieved through simple

menu choices, thus shielding the user from the technical complexity of managing encryption keys.

17. Management of keys The use of encryption to obfuscate sensitive information is of growing importance, but like all forms of security, failure

to control who has access to the keys can compromise transaction integrity. The TF provides the tools that allow the

respective parties to:

• create their own keys and ensure that they remain in their control

• manage key exchange

• manage how keys are used e.g. which keys are used with which relationship to minimise the risk of ‘global’ key

usage and assist with transaction integrity

• revoking of keys and their replacement such as when a staff member leaves

The TF client stores keys within the same encrypted/ striped files as the other data.

18. Authentication - Use of hashes The two parties in a relationship can agree to use one or more ‘secrets’ to authenticate each other. The parties may

exchange any number of these on a challenge-response basis depending of the level of authentication required. Unlike

the current process for logical access, the TF requires both parties to be satisfied and vary the level of authentication

based on their individual needs.

19. Optional creation of additional signing keys Users in a role have distinct signing keys and bind them to a particular role, providing they control the role. e.g. a private

person can change the signing key for them acting in the role as parent, but not as Purchasing Manager for their

employer.

An employer can bind a signing key to an employee in a role, but not to any role outside of work responsibilities.

20. Authorisation An individual acting in an organisation role may be required to authorise certain categories of transaction, for example

a legal document such as an authorisation to pay.

The TF manages the bindings between the person, legal role, authority, signing policy, signing request, document,

signature etc. to ensure only an authorised person can sign and that very high levels of assurance are achieved.

Unlike PKI, the TF has no difficulty in managing multiple signature scenarios.

21. Audit All actions performed on the TF are recorded locally in a tamper resistant, tamper evident audit trail. For example:

• When a user creates a new signature that event is recorded and timestamped using a TF time source

• When two parties sign a legal document, all events are recorded i.e. the transaction itself, the terms, the signing

event, etc.

Legal Rules 4

1. Point solutions vs End-to-end

solutions Point solutions are at the heart of the problem, as they not only

place a heavy burden on organisation who choose to implement

them, but create significant performance uncertainty when the

organisation integrates them.

Specific challenges exist around engineering them to achieve the

desired outcome, and the difficultly and lack of effectiveness

rises steeply with the number of point solutions being

employed.

Cyber security suffers from this in particular, and the situation

continues to worsen and more narrow and sophisticated

solutions come to market. With no two organisation being the

same, trying to decide which combination of solutions delivers

on the business need is increasingly difficult, let alone the

challenge of implementation.

The difficultly continues post implementation where

ascertaining whether the desired outcome has been achieved.

Certifying an infrastructure in its entirety is almost impossible,

but clearly highly desirable.

2. Roles The TF is deliberately role centric, as this is particularly

important in managing authority to act and liability.

No individual can act unless in an explicit role. There is no such

concept of a default role. Attributes of role management

ensure that they:

• are explicitly offered by the organisation responsible

• are explicitly accepted by the person taking the role

• are capable of differentiating between two different

people in the same role e.g. Administrator

• are capable of managing explicit delegation e.g.

manager to secretary

• allow a person to resign from a role

• allow a person to be dismissed from a role

• bind responsibilities to a person in said role, and

responsibilities/privileges are revoked when the role

ends (the binding between the person and the role is

broken)

Roles must:

• be explicitly offered by the organisation responsible

• be explicitly accepted by the person taking the role

• allow a person to resign from a role

• allow a person to be dismissed from a role

3. Non-Repudiation The term generally relates the ability of one party to deny their involvement in a given act (such as signing) in the

context of some kind of digital interaction. The expression isn’t strictly a legal term, although its impact may have

legal implications in the context of a dispute.

The TF helps to avoid this situation ever arising because of two very explicit features. First, the comprehensive

bindings that exist between every element of the Trust Framework, and second, the comprehensive auditing of all

actions.

Should a dispute arise, both parties can examine their respective audit trails (which in the context of the individual

transaction will be identical) and see that a given person (the other party) at a given time and date in a given process,

signed a specific document with a specific signature, (etc.).

Whether this is a civil or criminal matter, this would more than not only that of the other party, but that the act of

signing was performed by the other party, and further debate is unnecessary. Should the other party continue to

deny the act, the audit trail on their device could be examined and compared to the first party audit trail, which will

confirm the facts.

4. Manuscript signing The user, may choose to make use of the default signature created when the claim of identity was originally made.

This could be a signing ‘hash’ or could include an image of a signature. It is not an SSL key.

However, they may also create additional signing keys so they opt to sign differently for certain relationships for

example. Whichever approach is taken, the creation, alteration or disabling of a particular signature and method

(revocation) is recorded in the audit trail.

By ensuring that the user is responsible for the whole lifecycle of a given signature, and every time it is applied,

contract assurance is raised and evidential weight strengthened.

Advantages of Trust Framework Approach 5

The TF builds on the legacy of PKI and overcomes a number of weaknesses identified over

many years.

• The TF is explicitly based on the principles of law, evidence and traceability

• Interactions serve the needs of the two contracting parties in the interaction, not the needs of a third-party

Certificate Authority.

• High levels of identity assurance are provided by the tools incorporated in the TF

• Protection of information assets and IP are fundamental concepts incorporated into the design of the TF

• Information assurance, provenance and compliance are outcomes from the adoption of the TF

• Business processes are enabled across corporate and national boundaries

• Security is an outcome of our approach and is engineered into the design from the Outset

Objectives of a Trust Framework 6

• to provide a trust framework that enables parties in a contractually binding relationship to obtain high levels of

assurance in the areas of identity, information, credential and revenue.

• to mirror the physical world

• to enable evidential weight traceability of the actions of the parties to support dispute resolution

• to reduce the cost and complexity of legal and regulatory compliance

• to ensure that the customer experience is at least as good as at present and that the additional controls required

are not at the expense of that experience

ABOUT THE AUTHOR:

Lim Huck Hai

Huck Hai is the managing Director of Baker Tilly MH

Consulting Sdn Bhd and has over 30 years of

working experience in consulting and cyber

business. He heads a team of local and overseas

specialist developing, promoting and delivering

consulting and cyber services and solutions to

clients across both public and private sectors.

He was extensively involved in the

implementation of Malaysian Digital Signature

Law and the development of National

Information Security Policy for the purpose of

critical national information infrastructure

protection. He assisted regulators in the launch

of Derivatives industry and was involved in the

audit and preparation for the launch of business

operations for exchanges and clearinghouse

and their service bureau and assisted a number

of securities companies. He completed the First

WebTrust advisory and attestation for the digital

banking channels for one of the largest Asean

bank.

Huck Hai was previously a partner of Big4s and

a regional services leader of their consulting

practice. Huck Hai is the elected Vice President

of Association of Certified Fraud Examiners –

Malaysia Chapter and was a council member of

Malaysian Institute of Accountants and board

member of ISACA – Malaysia Chapter.

Qualifications

Bachelor of Economics (Accounting &

Computer Science), Monash University,

Australia

Diploma in Business Law, Staffordshire

University, UK

ACA, Institute of Chartered Accountants

England and Wales

Chartered Accountant, Malaysian

Institute of Accountants

Fellow CPA, CPA Australia

CPA, The Malaysia Institute of Certified

Public Accountants

Certified Information System Auditor

(CISA)

Certified Information Security Manager

(CISM)

Certified in Risk and Information

Systems Control (CRISC)

Certified Financial Planner (CFP), FPAM

Certified in the Governance of

Enterprise IT (CGEIT)

Qualified Auditor of Digital Signature Act

1997, registered with MCMC

Member Australia Computer Society

(MACS)

Professional Member, Institute of

Internal Auditors

Certified Fraud Examiner (CFE)

Lead Auditor, ISO27001 – Information

Security Management System

CONNECT WITH US:

Baker Tilly MH Consulting Sdn Bhd

C-10-07, Sunway Nexis,

No.1, Jalan PJU 5/1, Kota Damansara

47810 Petaling Jaya, Selangor, Malaysia

T: +603 6145 0889

F: +603 6158 9923

Baker Tilly Head Office

Baker Tilly Tower, Tower 1, Avenue 5

Bangsar South, 59200 Kuala Lumpur, Federal

Territory of Kuala Lumpur

T: +603 2297 1000

CONTACT PERSON:

LIM HUCK HAI

(MANAGING DIRECTOR)

T: +6017 200 3738

E: hlim@bakertillyconsulting.com.my