O-KEY chiave accesso banca
i codici generati sono creati da un algoritmo ben preciso. Lo stesso che viene
controllato dal sito in fase di login. Con 6 numeri variabili, avresti una possibilità
infinitesimale di azzeccare un codice creato da un algoritmo (che, tra l'altro, è blindato).
Chiavetta O-Key
L'algoritmo è uguale per tutte le chiavette, quello che cambia è il "seme" con cui viene inizializzato
l'algoritmo
e che è diverso per ogni chiavetta (potrebbe essere ad esempio un codice collegato al serial number del
dispositivo).
Sulla base del tuo codice (che la banca conosce) il sistema è in grado di sapere quale numero ti viene
generato
dal token in un dato momento e quindi verificarlo.
La chiavetta genera un codice ogni x secondi, infatti se premi più volte il tasto vedrai che per un po'
ricompare
lo stesso per poi cambiare...
Questo numero è utilizzabile (comunque solo 1 volta -> OneTimePassword) all'interno di una finestra
temporale
(16 secondi circa o poco più dopodiché scade ed è necessario rigenerarne uno più attuale).
In sostanza quindi, un'altra chiavetta genera un codice che sarà con probabilità altissima diverso da
quello generato
nello stesso istante dalla tua.
Formula matematica
Formula matematica? Cos(x) dove X aumenta di 1 ad ogni chiamata.
Facile, no?
Ovvio, se prima sei entrato con 99984, io banca che so che la formula
e' il coseno so che la tua chiavetta si trovava a cos(1), e mi aspetto
che i prossimi siano 99939 o 99862(*) ovvero cos(2) o cos(3), se te
n'esci con 17364 che potrebbe essere cos(100) o penso che ti sei messo
a giocare col tastino del token o che stai scazzando dei numeri. Tutti
gli altri numeri che poi non sono proprio generabili con la formula in
questione, ovviamente li scarto gia' in partenza.
(*) in questo esempio assumo che la banca abbia "tolleranza 2"
da aggiungere poi la crittografia !!!
il token usa lo standard oath per creare la chiave.
se vuoi capire come
funziona puoi trovare l'algoritmo qua:
http://www.openauthentication.org/resources.asp
algoritmo del TOKEN non e' riproducibile?
tramite reverse engineering tutto è riproducibile, se qualcuno con le adatte capacità ci si mettesse
d'impegno riuscirebbe benissimo a scoprire su che tipo di algoritmo lavora il token e riprodurlo
tramite un key-generator...
considera, però, che resta comunque un controllo in più rispetto rispetto ai soli userid e password.
In questo caso( improbabilissimo...) sarebbe cmq responsabile la banca per aver usato un algoritmo
che poi è stato craccato......
Ma l'algoritmo varia da chiave a chiave ? O cmq la "fonte" è un algoritmo con piccole modifiche per
ogni chiave?
Nel senso se un "malitenzionato" ha una okey, riesce a riprodurre solo tale okey o anche altre okey?
Se il caso è il secondo... lo trovo molto triste... nel senso: a quel punto trovavo + sicuri i "gratta e vinci"
P.S: considerate che inoltre ora il codice segreto è molto + corto... mi pare 5 numeri. mentre prima mi
pare fosse una cosa come 16 o 26 caratteri alfanumerici
Di solito in crittografia non è mai l'algoritmo ad essere segreto, ma la chiave (in questo caso il codice
associato
al token del cliente). La forza di un algoritmo sta anche e soprattutto nella difficoltà nel risalire alla
chiave
originaria conoscendo l'algoritmo e il risultato (funzione del tempo e del codice di inizializzazione)
il token usa lo standard oath per creare la chiave. se vuoi capire come funziona
puoi trovare l'algoritmo qua: http://www.openauthentication.org/
Partendo dal presupposto che attualmente è difficile implementare sistemi biometrici per l'accesso tramite internet, e quindi
la terza categoria viene automaticamente esclusa, la massima sicurezza si ha quando si combinano le altre due (SYK e
SYH). Per fare un esempio, basti pensare al bancomat: se per prelevare fosse sufficiente andare in banca con la tesserina,
senza dover conoscere il codice, oppure bastasse conoscere il codice senza dover avere la tessera, è evidente che sarebbe
molto più facile che qualcuno "non autorizzato" prelevasse dei soldi.
Il token quindi genera un codice che, poiché viene generato volta per volta, e non può essere riutilizzato, permette ai sistemi
di sicurezza della banca di riconoscere che effettivamente chi sta tentando di accedere è in possesso di quello specifico
token.
Qui entra in gioco una differenza tra due tipi di token:
•
Quelli "time-based" genera un codice che dipende dalla data e dall'ora, pertanto, il sistema di sicurezza della banca
può determinare che chi sta effettuando l'accesso è in possesso in quel momento del token. Il rovescio della medaglia è che
per fare ciò il token e server devono utilizzare un algoritmo che generi un codice basato sull'ora. Quindi è teoricamente
possibile che, con un adeguato numero di "osservazioni" un terzo possa riuscire a replicare l'algoritmo e a generare il codice
senza il token. Soprattutto però crea difficoltà di sincronia, dato che questa va mantenuta tra l'orologio interno del token e
quello del server, rendendo necessari ri-allineamenti per poter effettuare l'accesso.
•
Quelli "event-based" generano un codice che dipende "da un evento", che realtà più comune e più semplice il
numero di volte che viene richiesto di generare un codice. Tradotto, vuol dire che il token ha in memoria un elenco di codici,
che vengono restituiti in successione man mano che l'utente richiede un codice da utilizzare. Il server ha in memoria la
stessa tabella, anche se non "pretende" che tutti i codici vengano utilizzati, ma semplicemente quando viene utilizzato un
codice, tutti quelli che lo precedono nella tabella non possono più essere utilizzati. Si tratta di un sistema più semplice che ha
il vantaggio di non richiedere potenza di calcolo al token così come di generare codici che non hanno una correlazione tra
loro. Lo svantaggio è che non dà la garanzia al 100% che chi inserisce il codice sia in possesso del token in quel momento.
In teoria potrebbe essere qualcuno che ha avuto modo di entrare in contatto con il token precedentemente, e generare un
codice rimasto valido in quanto il legittimo proprietario non ha effettuato ulteriori accessi al sistema di banking.
In ogni caso, non vi è una categoria di token migliore "in assoluto" dell'altra, e si può dire che contribuiscono in modo
significativo alla sicurezza. Non bisogna fare però l'errore di affidarsi solamente al token: è sempre opportuno prestare una
certa attenzione alle password che si utilizzano, cercando sì di utilizzare password mnemoniche ma di non essere banali
utilizzando password facilmente identificabili o intuibili. Inoltre, è consigliabile cambiare periodicamente la i codici segreti di
utilizzo dei servizi di banca online (password e password dispositiva) almeno ogni 6 mesi o un anno, o quando si ha il minimo
sospetto che non siano più segreti.
La chiavetta non genera un numero a caso ma genera un numero preso a caso
tra una x quantità di quelli che le sono stati assegnati in fase di assemblaggio.
Parimenti sul server Sanpaolo Intesa c'e un database che ha associato al tuo
conto quel set di numeri che corrispondono a quella chiavetta che ti hanno dato,
man mano che tu usi i codici sul sito il database provvede ad autenticarti e a
disabilitarli pertanto solo i codici che la tua chaivetta può visualizzare sono
quelli che il database riconosce come validi per quello che tu non puoi usare
la chiavetta di un altro e un altro non può usare la tua e i codici una volta usati
non sono più riusabili.
La chiavetta genera al volo un numero partendo da un codice univoco insito nella
chiavetta e dall'ora corrente (quantizzata ai 10 secondi. Si, la chiavetta contiene
un orologio.). Infatti il codice deve essere utilizzato entro 16 secondi dalla generazione,
poi diviene inutilizzabile. Conoscendo l'ora corrente e il codice della chiavetta il server
puo' controllare il numero generato.
Il codice non e' casuale, ma e' una funzione del numero della chiavetta, data e ora.
Il server sa qual e' il numero della tua chiavetta, data e ora e fa lo stesso calcolo,
cosi' vede se il numero che gli hai dato e' giusto. Se uno conoscesse la funzione,
potrebbe calcolarla per qualunque chiavetta, ma si spera che questa funzione
sia segreta :-) Perche' se tu esci e rientri non accetta piu' il codice? Perche'
qualcuno potrebbe spiarti (con una telecamera, o via computer), vedere il tuo
codice ed usarlo su un altro computer. Quindi il computer centrale, quando
riceve un codice, lo segna come usato.
...e oltretutto scade, trascorso poco più di un minuto. Se provi a segnarti il codice e
ad utilizzarlo 5 minuti dopo non te lo accetta più perchè è funzione anche del tempo
in cui è stato generato. Peccato non esista un programmino con lo stesso algoritmo,
da caricare sul PC, in modo da non avere un altro aggeggio da portarsi dietro.
Di certo una volta usata la chiave il sistema centrale non la accetta più. Poi ho visto varie
implementazioni sia con algoritmi dedicati (per cui i numeri non sono poi così casuali) sia
con tabelle precaricate. In questo casi i numeri possono davvero essere "casuali" ma sono
già caricati sia nella chiavetta che nel server. In caso di disallineamento il server sa che indietro
non si torna e quindi verifica se la tua chiave è presente qualche record più avanti.
Marco / iw2nzm
FUNZIONAMENTO E CARATTERISTICHE
Le password sono elaborate dal token stesso tramite un algoritmo a chiave simmetrica
(3-DES â " Triple Data Encryption Standard) che cifra uno o piu' di uno dei seguenti
elementi: · un valore numerico (ad esempio un contatore numerico sequenziale);
· il tempo, ovvero l⠙istante temporale calcolato da un orologio interno al token;
· un challenge, ovvero un valore fornito da un⠙applicazione esterna.
· La validazione dell⠙utente
è a carico di un Authentication Server, sincronizzato con l⠙orologio del token, e su cui
è eventualmente memorizzabile il valore di challenge. L'Authentication Server
è in grado di rielaborare, tramite la stessa chiave simmetrica dell'utente, la medesima password.
Soluzioni per l’autenticazione
!
#
$%
"
#
"
&
'
#
$%
&
!
#
'
#
(
*+
+
)
)
#
+
$
)
)
"
+ #
#
Authentication Server One Time Password - AS OTP
,
/
'
)
./ + ##
#
#
)0 +
$% #
./ "
#
0 $
#
#
#
$
FUNZIONAMENTO E CARATTERISTICHE
2./ "
'
#
$
"
.
#
1
#
"
(
• Validare l’identità di un utente in rapporto alle credenziali fornite (valore della password
temporanea e riferimento al token che l’ha generato).
• Amministrare un token tramite le funzioni di: importazione, ovvero di caricamento massivo,
nell’anagrafica del cliente dei valori associati ai token (numero seriale, chiave di cifratura del
token, ecc.);
• risincronizzazione dell’orologio del server con quello del token;
• verifica del funzionamento del token (attivo, non attivo, bloccato, ecc.) e dell’associazione
corretta all’utente a cui è stato assegnato;
• registrazione degli eventi (logging).
*
'
"
/
'
#
2.
/%
*
2
)
2
.3
+
$
REQUISITI MINIMI DI SISTEMA
2
#(
' )
4555
, 7)*
8 9 :,8 *
!;: *
82 2
#
45562 # +
% 7
+
TOKEN One Time Password (OTP)
*/.< ./ "
#
'
#
#
#
$%
=
=
/.<
'
#
./
=
##
(
#
'
*$
FUNZIONAMENTO E CARATTERISTICHE
%
'
0
@
2
+
A
#
)
A
#
#
A
#
#
#
A
%#
"
"#
#
#
=
#
)
6:> 2? /
>
(
+
B
0 B
$
2 #
$%
=
0
2 # "
'
$%
"
0
#
#
$ #
#
/.<
./
(
A
'
#
# B
A
#
#
#
0
$
+
A
A
#
0
)
) 0
#
B
+
B
B
A
A
&
B
#
#
#1
#
#
)
*
$
+
$
REQUISITI MINIMI DI SISTEMA
"
#
'
#
#
$%
=
2 #
$
TrustAccess
/
%
•
"
' $
(
#
'
(
*
>1
'
B
•
•
#
B
B
•
$
*
/
:
$
"
/
#
#
#
:
$*
#
#
-#
$
Descrizione
/
" #
$%
$>
/
#
)
(
$
+
#
'
"
$
%#
#
*)
'
+#
#
%#
'
./
) 0 ./ + /
+
./ )
.
#
$
* "
/
%
#
$
"#
#
/
#$
#
*
-
#
' $
"
+%
'
#
$
'
#
#
/
Requisiti minimi
A2
.
# (2, 2
A
(2, 2 D
A;
D ;(E4F; @
A
A2
.
# (% 7
A;
D ;(CH; @
A
4$
C
6FC
Target
*# -
$*
!;
)
:
0
2 2 G$
7
+
#
" #
#
I
$
"
#
#
%
#
#
$
:
#
2 #
$
*
#