O bezpečnosti mobilního bankovnictví se toho již řeklo mnoho. Je ale možné tyto poznatky přenést na multi-banking aplikace (aplikace, které umí spravovat více bank současně)? Na přednášce ukážu, jaké nové a dosud neřešené problémy multi-banking aplikace (a otevřená bankovní API) přináší například v oblasti autentizace či ochrany osobních dat, ale hlavně to, jak takové aplikace udělat bezpečně a současně pohodlně z pohledu koncového uživatele.

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

2. Single-banking

3. Smart Cards & Devices Forum 2013
Řešení bezpečnosti mobilního
single-bankingu bylo velkým
tématem cca v letech
2010-2014.

4. Doplňková témata (SSL, logování, …).
Rozumně zvládnuté napříč bankami.
Hlavním tématem je autentizace.
Problémy s inovativními vlastnostmi.

5. 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.

6. Z českých bank má nejobecněji
a z pohledu rozšiřitelnosti
nejlépe bezpečnost řešené
Mobilní eKonto od
Raiffeisenbank.

7. PowerAuth 2.0
http://powerauth.com/
Řešením Mobilní eKonto od
Raiffeisenbank je silně
inspirovaný free a open-source
protokol PowerAuth 2.0.

8. Open-source a zdarma ke stažení.
MONETA Money Bank.
“Poučený”, referenční protokol.

9. 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.

10. 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.

11. Multi-banking

12. Otevřené bankovní služby a API.
Vstup 3. stran a #fintech startupů.
Dopady legislativy PSD2.

13. Problémy specifické pro multi-
banking se objevily během
návrhu aplikace Zingly.

14. Lze řešit různými způsoby.
Ne kompromis v bezpečnosti či UX.
Nové bezpečnostní problémy.
Nejspíš nechceme super-autoritu.

15. 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.

16. Příklad 1
Více bank, jeden PIN kód

17. BankyUživatelé
activation id
PIN(x)
knowledge
Banka A
V případě jedné banky je
“knowledge” related faktor
autentizace uložený pomocí PIN
kódu.

18. BankyUživatelé
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.

19. BankyUživatelé
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?

20. Situace 1
Aplikace nezná PIN
Jak přidat další banku?

21. BankyUživatelé
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.

22. BankyUživatelé
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.

23. Situace 2
Pro X bank, N * X pokusů
Jak zajistit pouze N pokusů?

24. BankyUživatelé
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ě.

25. BankyUživatelé
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.

26. S každou další bankou
trochu méně bezpečné
Killer marketing slogan?
:)

27. Situace 3
Synchronizace
Jak zabránit zablokování pouze jedné banky?

28. BankyUživatelé
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.

29. BankyUživatelé
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.

30. Řešení: Centrální komunikační
hub a secure vault

31. PowerAuth Server PowerAuth Server
Zingly API Server Zingly API Server
Zingly Multi-Banking Hub Server
Banka A Banka B
BankyUživatelé
PowerAuth Server
Zingly
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.

32. Uživatelé PowerAuth 2.0 Client
PowerAuth Server PowerAuth Server
Zingly API Server Zingly API Server
Zingly Multi-Banking Hub Server
Banka A Banka B
BankyUživatelé
PowerAuth Server
Zingly
Internetové
bankovnictví
Internetové
bankovnictví
VAULT
knowledge
activation id
PIN(x)
activation id
PIN(x)
activation id
PIN(x)
knowledge knowledge

33. Příklad 2
Data na všech internetech

34. To nejcenější na
otevřeném API jsou
data.
— zaslechnuto na Internetu
“

35. Data z bankovního API
jsou radioaktivní odpad
který nikdo nechce
skladovat.
“

36. 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…

37. Databáze - Banka
🔒
Banky dnes investují
nemalé peníze do
ochrany dat svých
klientů.

38. Replika - Startup A
Databáze - Banka
Cloud - Startup B
Záloha na Dropboxu
Startup C
Bankovní API
🔒
🔒
🔒
🔒
Pokud tato data
následně vystaví
pomocí API, očekává
se, že je zabezpečí i
všechny ostatní služby.

39. Replika - Startup A
Databáze - Banka
Cloud - Startup B
Záloha na Dropboxu
Startup C
Bankovní API
🔒
🔒
🔒
🔒
Tento náklad se
následně “nerozpočítá”
- celkové náklady se
sčítají, všichni musí
investovat do ochrany
dat.

40. Replika - Startup A
Databáze - Banka
Cloud - Startup B
Záloha na Dropboxu
Startup 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…

41. Replika - Startup A
Databáze - Banka
Cloud - Startup B
Záloha na Dropboxu
Startup C
Bankovní API
💀
💀
💀
💀
V podstatě je to tak, že
dojde ke ztrátě dat,
která chrání všechny
replikujícíc služby.

42. Replika - Startup A
Databáze - Banka
Cloud - Startup B
Záloha na Dropboxu
Startup C
Bankovní API
💀
💀
💀
💀
A násobně investované
prostředky se
nenávratně ztratí…

43. Jeden “nešika” to kazí všem.
Náhodně umístěné repliky dat.
Drahé, neefektivní.
Nemožnost kontrolovat svá data.

44. Řešení: End-to-end šifrování
a on-demand služby

45. 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.

46. 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ě.

47. 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.

48. 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á.

49. Banka A
BankyUživateléZingly
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

50. Shrnutí

51. Bezpečný trezor a E2E šifrování.
Banka jako bezpečná databáze.
Nové bezpečnostní problémy.
On-demand služby.

52. Děkuji
Petr Dvořák
e-mail: petr@lime-company.eu
twitter: @zinglyapp
http://powerauth.com/