www.directtrust.org 1101 connecticut ave nw, washington, dc 20036 direct texting a concept/proposal...

www.DirectTrust.org1101 Connecticut Ave NW, Washington, DC 20036

Direct Texting

A Concept/Proposal from DirectTrust to In-Bundle HISPs and CAs

DirectMessaging

DirectTexting


The basic idea

• To leverage DirectTrust’s security and trust infrastructure, and our national network, to provide open, standards-based, secure, and identity validated Direct texting.

• HISPs could offer Direct texting services to existing and new customers alongside their Direct messaging services.

• Anyone on the network could connect with anyone else on the network via Direct texting apps.

• DirectTrust would hold license to open technical specification for Direct texting, analogous to the Applicability Statement for Direct messaging.

• Other licensing arrangements to be considered. DirectMessaging

DirectTexting


• Defining the smartphone texting markets• Barriers to healthcare texting • What the healthcare market needs• The opportunity for the DirectTrust network• How to accelerate process• Next steps

Outline

DirectMessaging

DirectTexting


1. Provider to Provider: Texting between providers including Protected Health Information (PHI). Happens regularly; hospitals are trying to prohibit for compliance reasons.

2. Hospital to Provider: Aka paging, this has been used for a long time. Hospitals and providers would prefer to avoid dedicated pagers, and have the ability to include PHI information in such texts (currently not allowed).

3. Provider to Patient: Texting between providers and patients. Widespread for appointment reminders. Increasing, especially with younger patients, for other purposes.

The three use cases


1. No guarantee of privacy: Texts within iOS, Android and BBM are encrypted, but cross platform texts use SMS network and there is no guarantee that they will be encrypted at carriers.

2. Complete lack of auditability: End to end encryption within the iOS, Android and BBM networks prevent audits. The SMS networks do not have any easy auditability.

3. Standards Vacuum: Closest spec (XMPP/Jabber/XCP) has ‘perfect forward security’ model (no auditability) or no end user PKI credentials.

4. Lack of reliability: Cross platform texts, or hospital paging, lack guaranteed delivery. 2-5% of all texts are lost.

5. Proprietary Silos: Private app-based solutions solving some of the above exist. They are siloed, centralized services. They do not inter-operate and either lack end to end encryption or auditability. Also lack strong identity proofing and authentication. Providers unlikely to use different apps for texting different providers or patients.

The current barriers


1. An open standard for healthcare texting stewarded by a trusted and competent neutral organization.

2. Interoperable end to end privacy. Implication of a PKI solution is unavoidable.

3. The solution must have end to end privacy WITH auditability AND WITH strong identity proofing and authentication.

4. The solution must have guaranteed delivery with return receipts.

5. The solution must work on any platform – TODAY, without persuading Apple, Google, BlackBerry, Microsoft, etc. to endorse standard.

The solution needed


• DirectTrust is a trusted organization capable of stewarding the healthcare texting standard in partnership with ??

• There are two aspects to any such standard:1. The operational standards, e.g. Certificate Policy, ID proofing,

accreditation via EHNAC-DirectTrust.2. The technical specs.DirectTrust has already done all the work on the operational standards.

DirectTrust accreditation and credentials can be reused by a PKI based healthcare texting standard. Leveraging the work already done by DirectTrust and its members is key to this opportunity’s success.

• DirectTrust in-bundle HISPs are ideally positioned to expand their service offerings to include Direct secure texting and paging, starting with existing customer base of hospitals, health systems, medical practices, etc.

The DirectTrust opportunity


• Part of incubator set up with (unusual) business model:• Identify market vacuum, invent, build proof of concept,

license/sell intellectual property and s/w• Not a traditional software or SAAS vendor

• No direct sales to enterprises or consumers

• Invest little… Sell for little more…

• Status of technology relevant to this conversation:• Owns or licenses relevant intellectual property• Well developed alpha code (ready to show customers)• Exploring various licensing/sale options

• E.g. make SPEC open; license app and server software

3pTALK Background


Capabilities Walk Through

1. Initial multifactor authentication to 3pTALK App & Switch

2. User to user secure messaging

3. Enterprise to user messaging (aka paging)

4. Focus on graphical and digital signatures

5. Site and user mutual authentication and light federation

6. Audit

SWITCHAudit Server

Admin Server

OrgInterface

CA


Back Up – More Info

• If you want to try app, we will set up an account on our guest network. Please contact:– Ravi Ganesan, [email protected], +1.415.680.5746– Note we currently support iOS and Android. BlackBerry is supported

via Android side loading (no PUSH notifications).

• Or, the screen shots that follow give you a taste of the product.– Messaging types – CONFIRM, QUERY, OPTION and INFORM.– OTP and Federation Lite flow– Sample Org Interface screen shot– Sample Audit System screen shot

• You can also see videos at http://3ptalk.com/appinaction/


Initial Two Factor Authentication

SWITCH

OOBA

• OOBA could be replaced by existing multifactor authenticator, or trusted credential broker for initial authentication.

• Note email step shown on right would usually not be needed.

• At end of login user has a PKI credential. The CA could be co-resident/external.

CA


P2P Messaging – Privacy + Auditability

SWITCH

Process•Alice sends Bob message encrypted with session key.•Session key enveloped with Bob’s public key.•Session key enveloped with Audit Service’s public key.•If first communication, Bob is asked if he wants to accept messages from Alice.•If he says yes, then he and Alice share session key for future communication. •Audit server retrieves encrypted messages. Can provide data to authorized party.

Audit Server

Benefits•Privacy: True end to end encryption; Messages opaque to SWITCH.•Auditability: Audit server, which could be a 3rd Party middleman, similar to a federation anonymizer, can provide message if required.

Admin Server


Secure Enterprise Paging

• Web based interface for an enterprise back office to message users (aka paging).

• A hospital that has deployed pagers to their medical staff can use the 3pTALK app instead.

• Unlike SMS, 3pTALK has guaranteed delivery and is secure. Also saves paging costs.

• Ability to do group messaging, pre-scheduled and/or recurring messaging.

• Goal is to get these APIs embedded in systems like EHRs, or integrated with banking systems.

SWITCHAudit Server

Admin Server

OrgInterface


Message Types

• Supports five message types for both P2P and enterprise to user.

• CHAT: Familiar SMS/text metaphor.• SIGN: To be discussed later.• INFORM: Informational one-way; e.g.

“remember to take your medication”, or “your account balance has insufficient funds”.

• CONFIRM: Requires yes/no answer; e.g. “Did you do your cardio today?”, or “Did you schedule a wire of $10,000 to Count Dracula”.

• QUERY: Allows free form response; e.g. “what is your blood pressure today?”.

• OPTION: Same as QUERY except sender provides multiple choices.

Messaging, transaction authentication, signing and more…


Graphical and Digital Signatures

• End users who get a signature request, simply perform a graphical signature.• Behind the scenes, an X.509 compliant digital signature is being generated.• Recipient has both graphical and digital signature, and messaging logs at audit

server, to gain a high degree of non-repudiation and evidence if needed.


Multifactor Authentication

• Process– User enters ID at Relying Party (RP)– RP sends ID to SWITCH– SWITCH computes OATH OTP and sends OTP

and RP Name to app– User displays OTP at app, and enters OTP at RP– RP asks SWITCH to verify

• Benefits – Super simple “zero crypto” interface for RPs– No seeds at app or RP

SWITCHRelyingParty


Back Up – More Info

• If you want to try app, we will set up an account on our guest network. Please contact:– Ravi Ganesan, [email protected], +1.415.680.5746– Note we currently support iOS and Android. BlackBerry is supported

via Android side loading (no PUSH notifications).

• Or, the screen shots that follow give you a taste of the product.– Messaging types – CONFIRM, QUERY, OPTION and INFORM.– OTP and Federation Lite flow– Sample Org Interface screen shot– Sample Audit System screen shot

• You can also see videos at http://3ptalk.com/appinaction/


Messaging - CONFIRM


Messaging - QUERY


Messaging - OPTION


Messaging - INFORM


Settings and View Certificate

Various settings can bemanaged here.

User views their certificate.Only place in product that

our “invisible PKI” is visible!


SWITCHRelyingParty


Step 1: User enters ID into web site.



Step 2: RP passes ID to SWITCH. Pushes OTP to app. User enters in web site.


SWITCHRelyingParty


Step 3: RP sends SWITCH OTP. If positive response, user is logged in successfully.


Screen shot from Org Interface


Screen shot from Audit System

www.directtrust.org 1101 connecticut ave nw, washington, dc 20036 direct texting a concept/proposal...

Documents