Bezpečnost mobilních multi-banking aplikací Smart Cards & Devices Forum 2016

@Lime_CompanyLime

Single-banking

Smart Cards & Devices Forum 2013

Řešení bezpečnosti mobilního single-bankingu bylo velkým

tématem cca v letech 2010-2014.

Doplňková témata (SSL, logování, …).

Rozumně zvládnuté napříč bankami.

Hlavním tématem je autentizace.

Problémy s inovativními vlastnostmi.

Touch ID

Apple Watch

Android Widget

Today Screen

Android Wear

Banky mají dnes problém implementovat bezpečně

některé z těchto funkcí. Jejich autentizační řešení nepočítá

s různými faktory autentizace.

Z českých bank má nejobecněji a z pohledu rozšiřitelnosti

nejlépe bezpečnost řešené Mobilní eKonto od

Raiffeisenbank.

PowerAuth 2.0http://powerauth.com/

Řešením Mobilní eKonto od Raiffeisenbank je silně

inspirovaný free a open-source protokol PowerAuth 2.0.

Open-source a zdarma ke stažení.

MONETA Money Bank.

“Poučený”, referenční protokol.

Multi-factor autentizace

End-to-end šifrování

Bezpečné úložiště

PowerAuth 2.0 byl původně pouze autentizační protokol, ale

postupem času v něm byla vyvinuta podpora pro E2E šifrování a secure vault.

End-to-end šifrování

a bezpečné úložiště vznikly

jako side-efekt při návrhu

bezpečné autentizace.

“

Tyto dvě dodatečné vlastnosti, které vznikly jako “side-efekt” pak v případě multi-banking

aplikací hrají překvapivě zcela zásadní roli.

Multi-banking

Otevřené bankovní služby a API.

Vstup 3. stran a #fintech startupů.

Dopady legislativy PSD2.

Problémy specifické pro multi-banking se objevily během

návrhu aplikace Zingly.

Lze řešit různými způsoby.

Ne kompromis v bezpečnosti či UX.

Nové bezpečnostní problémy.

Nejspíš nechceme super-autoritu.

Problémy distribuovaného multi-bankingu

Ideální stav je takový, že kdokoliv může postavit aplikaci nad bankovními službami

a realizovat funkce typu “bezpečné platby”. Multi-banking tak není koncentrovaný do

jedné centrální autority.

Příklad 1

Více bank, jeden PIN kód

Ban

kyUži

vate

lé

activation id

PIN(x)

knowledge

Banka A

V případě jedné banky je “knowledge” related faktor

autentizace uložený pomocí PIN kódu.

Ban

kyUži

vate

lé

activation id

PIN(x)

activation id

PIN(y)

X = Y ?

knowledge knowledge

Banka A Banka B

Co se ale stane, pokud má uživatel dvě banky kde je “knowledge” related faktor uložený pomocí jednoho

stejného PIN kódu.

Ban

kyUži

vate

lé

activation id

PIN(x)

activation id

PIN(?)

knowledge knowledge

Banka A Banka B

A co se stane, když do tohoto stavu uživatele dotlačíme tím, že mu pro dvě banky dáme jednu

aplikaci?

Situace 1

Aplikace nezná PIN Jak přidat další banku?

Ban

kyUži

vate

lé

activation id

PIN(x)

knowledge

Banka A Banka B

Jakým způsobem probíhá přidání další banky? Aplikace

nezná PIN kód, ale umí pomocí zadaného PIN kódu odemknout

“knowledge” related faktor.

Ban

kyUži

vate

lé

activation id

PIN(x)

activation id

knowledge knowledge

Banka A Banka B

Pro uložení “knowledge” faktoru druhé banky je potřeba správný

PIN kód, který ale aplikace nezná a neumí ho lokálně zjistit.

Situace 2

Pro X bank, N * X pokusů

Jak zajistit pouze N pokusů?

Ban

kyUži

vate

lé

activation id

PIN(x)

activation id

PIN(x)

knowledge knowledge

Banka A Banka B

Další problém je, že uložené autentizační prostředky více

bank je možné používat nezávisle na sobě.

Ban

kyUži

vate

lé

activation id

PIN(x)

activation id

PIN(x)

knowledge knowledge

Banka A Banka B

Útočník tak získá N pokusů na přihlášení do

každé z X uložených bank.

S každou další bankou trochu méně bezpečné

Killer marketing slogan?

:)

Situace 3

Synchronizace

Jak zabránit zablokování pouze jedné banky?

Ban

kyUži

vate

lé

knowledge

activation id

PIN(x)

knowledge

activation id

PIN(x)

Nová platba - neúspěšná autentizace

Banka A Banka B

Při neúspěšné autentizaci do jedné banky v dané bance klesne počet pokusů

a v ostatních bankách nikoliv.

Ban

kyUži

vate

lé

knowledge

activation id

PIN(x)

knowledge

activation id

PIN(x)

0 pokusů BLOCKED

5 pokusů ACTIVE

Banka A Banka B

Jedna banka se tak může kompletně

zablokovat s tím, že ostatní banky mají

stále aktivní prostředky.

Řešení: Centrální komunikační

hub a secure vault

PowerAuth Server PowerAuth Server

Zingly API Server Zingly API Server

Zingly Multi-Banking Hub Server

Banka A Banka B

Ban

kyUži

vate

lé

PowerAuth Server

Zin

gly

Internetové bankovnictví

Internetové bankovnictví

Centrálně orchestrovaný autentizační prostředek drží “master autentizační data”, která jsou použita pro autentizaci

a odemčení secure vaultu, který na zařízení udržuje šifrovaná autentizační data do jednotlivých bank. Přihlášení pak probíhá ve dvou krocích: 1) odemčení vaultu autentizací

vůči master aktivaci a odšifrování autentizačních dat jednotlivých bank a 2) přihlášení k jednotlivým bankám.

Uži

vate

léPowerAuth 2.0 Client

PowerAuth Server PowerAuth Server

Zingly API Server Zingly API Server

Zingly Multi-Banking Hub Server

Banka A Banka B

Ban

kyUži

vate

lé

PowerAuth Server

Zin

gly

Internetové bankovnictví

Internetové bankovnictví

VAULT

knowledge

activation id

PIN(x)

activation id

PIN(x)

activation id

PIN(x)

knowledge knowledge

Příklad 2

Data na všech internetech

To nejcenější na

otevřeném API jsou

data. — zaslechnuto na Internetu

“

Data z bankovního API

jsou radioaktivní odpad

který nikdo nechceskladovat.

“

S bankovními daty by měli nakládat pouze lidé, kteří jsou na to dobře vybaveni, mají adekvátní dress code a jsou za to dobře

placeni. Čili bankéři…

Databáze - Banka

🔒

Banky dnes investují nemalé peníze do ochrany dat svých

klientů.

Replika - Startup A

Databáze - Banka

Cloud - Startup B

Záloha na DropboxuStartup C

Bankovní API

🔒

🔒

🔒🔒

Pokud tato data následně vystaví

pomocí API, očekává se, že je zabezpečí i

všechny ostatní služby.

Replika - Startup A

Databáze - Banka

Cloud - Startup B

Záloha na DropboxuStartup C

Bankovní API

🔒

🔒

🔒🔒

Tento náklad se následně “nerozpočítá”

- celkové náklady se sčítají, všichni musí

investovat do ochrany dat.

Replika - Startup A

Databáze - Banka

Cloud - Startup B

Záloha na DropboxuStartup C

Bankovní API

🔒

🔒

💀🔒

Pokud se následně objeví jeden hříšník,

který data neuchrání, je ochrana dat zmařena.

Historie plateb se nedá revokovat…

Replika - Startup A

Databáze - Banka

Cloud - Startup B

Záloha na DropboxuStartup C

Bankovní API

💀

💀

💀💀

V podstatě je to tak, že dojde ke ztrátě dat,

která chrání všechny replikujícíc služby.

Replika - Startup A

Databáze - Banka

Cloud - Startup B

Záloha na DropboxuStartup C

Bankovní API

💀

💀

💀💀

A násobně investované prostředky se

nenávratně ztratí…

Jeden “nešika” to kazí všem.

Náhodně umístěné repliky dat.

Drahé, neefektivní.

Nemožnost kontrolovat svá data.

Řešení: End-to-end šifrování

a on-demand služby

Cena za 1 MB úložiště ($)

0

0,008

0,015

0,023

0,03

1998 2000 2002 2004 2006 2008 2010 2012 2014

$0.0000283

http://www.jcmit.com/disk2015.htm

Uložiště jsou velmi levná, v čase cena

radikálně klesla.

http://drpeering.net/white-papers/Internet-Transit-Pricing-Historical-And-Projected.php

0

300

600

900

1200

1998 2000 2002 2004 2006 2008 2010 2012 2014

Cena za 1 Mbps ($)

$0.63

Totéž ovšem platí i pro konektivitu, relativní pokles pak je ještě vyšší, než pro cenu

úložiště.

Banka bude fungovat jako

bezpečná finanční databáze,

nebude nutné replikovat data

v jednotlivých službách. — odvážná predikce

“

Banku si představte jako “lokální tabulky” vaši databáze

zprostředkované přes API.

Služby, které dnes replikují

data budou umět fungovat

na vyžádání, v reálném čase

a za kontroly uživatele. — odvážná predikce

“

Tato data si pak služby 3. stran budou moci kdykoliv vyžádat, bez nutnosti replikace dat. Ukládat pak budou muset nejvýše autentizační data, která jsou ale revokovatelná.

Banka A

Ban

kyUži

vate

léZ

ing

ly

Příklad:On-demand PFM

1. Aplikace si stáhne data z více bank,data jsou chráněna E2E šifrováním.

2. Aplikace si odšifruje data, uživatel označí data, která chce odeslat k analýze.

3. Data se odešlou k real-time analýze do cloudové služby, zpět je vrácena analýza. Data se neukládají.

PFM Engine

🔒

Banka B

🔒

🔒

Zingly Multi-Banking Hub Server

🔒 🔒PFM

= personal finance

management

Shrnutí

Bezpečný trezor a E2E šifrování.

Banka jako bezpečná databáze.

Nové bezpečnostní problémy.

On-demand služby.

Děkuji

Petr Dvořák e-mail: petr@lime-company.eu twitter: @zinglyapp

http://powerauth.com/