U2F FIDO: Difference between revisions
| Line 1: | Line 1: | ||
= Google Quellen = |
= Google Quellen = |
||
Slides von der Google Präsentation: |
[https://docs.google.com/presentation/d/16mB3Nptab1i4-IlFbn6vfkWYk-ozN6j3-fr7JL8XVyA/edit?pli=1#slide=id.g19c09a112_2_0 Slides] von der Google Präsentation: |
||
https://docs.google.com/presentation/d/16mB3Nptab1i4-IlFbn6vfkWYk-ozN6j3-fr7JL8XVyA/edit?pli=1#slide=id.g19c09a112_2_0 |
|||
Beispiel Demo: |
|||
https://u2fdemo.appspot.com/ |
[https://u2fdemo.appspot.com/ Beispiel Demo], welche ausschließlich mit einem Gnubby und einem existierenden Google Account funktioniert: |
||
[http://fidoalliance.org/specs/fido-u2f-raw-message-formats-v1.0-rd-20140209.pdf Dokumentation] der Daten, welche an und von dem Gnubby übermittelt werden: |
|||
= API Referenzen = |
= API Referenzen = |
||
Revision as of 19:14, 30 September 2014
Google Quellen
Slides von der Google Präsentation:
Beispiel Demo, welche ausschließlich mit einem Gnubby und einem existierenden Google Account funktioniert:
Dokumentation der Daten, welche an und von dem Gnubby übermittelt werden:
API Referenzen
Javascript referenz, welche in der Chome extension verwendet wird: http://fidoalliance.org/specs/fido-u2f-javascript-api-v1.0-rd-20140209.pdf
Git Repositorys
Original Repo von Google mit Beispielcode:
https://github.com/google/u2f-ref-code/
Modifiziertes Repo von Marc. In dem u2f-ref-code wurde ein sehr einfacher Login als Beispiel implementiert. Auch wird in u2f-chrome-extension der Localhost akzeptiert, welcher in dem original mit einem "Error 2" abgelehnt wird:
https://github.com/MarcKe/u2f-ref-code
Erläuterung der Änderung
Um den Localhost zu akzeptieren, müssen folgende Zeilen in der "etld.js" eingefügt werden:
if (host.indexOf(':') != -1) {
host = host.substring(0, host.indexOf(':'));
}
+
+ if (host == "localhost") {
+ console.log("localhost");
+ return host;
+ }
// Loop over each possible subdomain, from longest to shortest, in order to
// find the longest matching eTLD first.
var next = host;
Beispieltoken der erstellt wird
Interessant ist hierbei die Gültigkeit des Zertifikats. Dies kann jedoch durch die Version (v0), also die frühe Entwicklung Token selbst zu tun haben.
new token:
public_key: BPEfrHYFJIe7aMAljNIq3Gv7nlHdhkxjZYEOzpMhjsz6zXxJVmPZgW7hr6YEkLInTTRSKlhTBST80mu6vx4LPIU
key_handle: xGDwceuts3WnDLvAuCUvPj6MZ59EMRusdd9SpM6ipQIO_lYOD40NW9HzwdkcwaWY1xvl54G5MuUDTfbRIrpaxw
counter: 0
attestation certificate:
Version: V3
Subject: OID.2.5.4.45=#030A00013284FFFFFFFF0444, CN=Google Gnubby v0
Signature Algorithm: SHA256withECDSA, OID = 1.2.840.10045.4.3.2
Key: Sun EC public key, 256 bits
public x coord: 76325047710147689659458271283597733852774968588358871702791068908014891073689
public y coord: 51805930702706814209933188884277181691700110245786325738983307203119170576020
parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)
Validity: [From: Fri Jun 01 02:00:00 CEST 2012,
To: Thu Jun 01 01:59:59 CEST 2062]
Issuer: CN=Gnubby HSM CA 00
SerialNumber: [ 013284ff ffffff04 44]
Algorithm: [SHA256withECDSA]
Signature:
0000: 30 44 02 20 78 7D 36 9D 3D E3 ED CE ED AA 8D 9A 0D. x.6.=.......
0010: 6D 36 25 50 D3 39 98 27 11 DA 1D A5 A7 97 A4 93 m6%P.9.'........
0020: 93 BB 0C 94 02 20 17 93 7E C1 61 BF 14 61 FA 29 ..... ....a..a.)
0030: D9 CF 8A A5 BA CA 23 2E E6 52 52 A9 06 D1 31 9F ......#..RR...1.
0040: A2 94 68 F6 2A 70 ..h.*p
u2f-gae-demo
Dieses Beispiel von Google funktioniert auf einem Server mit der Google App Engine. Dieser muss für eine JBoss oder Tomcat Server angepasst werden.