smart cards and devices forum 2016 - bezpečnost multi-banking mobilních aplikací
TRANSCRIPT
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.
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.
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.
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?
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.
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.
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.
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
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…
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.
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
Bezpečný trezor a E2E šifrování.
Banka jako bezpečná databáze.
Nové bezpečnostní problémy.
On-demand služby.