epass2003 a digitális kulcskarika

Az egyik topikban volt szó egy hardveres kulcsról, ami tanúsítványokat/kulcsokat tárol. Nekem nagyon megtetszett, rendeltem is belőle, a UPS egész gyorsan meghozta a postához képest. :) Első benyomásom amikor kivettem a dobozból, hogy pici. No nem mintha baj lenne, de nagyobbra számítottam a képek alapján. Amikor bedugtam a gépbe, egy zöld led kezdett világítani jelezvén hogy működik. Később kiderült azt is jelzi ez a led villogással, hogy éppen írok vagy olvasok az eszközön.
De milyen kulcsokat tárolhatnék rajta?? Ami eszembe jutott SSH, VPN, és a dm-crypt. Ebből kettő meg is valósult, a harmadikat félretettem.

Telepítés:
----------
Nekem semmi probléma nem jött közbe itt. Felraktam a csomagokat és öröm bódottá! :)

# apt-get install opensc

# apt-get install libccid
# apt-get install engine_pkcs11

Első lépések
------------
Amint telepítettük az eszközhöz szükséges csomagokat, nézzük meg, hogy látja e a program az eszközt.

$ opensc-tool --serial

$ opensc-tool --reader 0 --name

Alapok:
-------
Az eszköz formázása kihagyhatatlan lépés, a többi inkább csak akkor kell, ha "vész" van.

Formázni az eszközt:
$ pkcs15-init --create-pkcs15 --profile pkcs15+onepin --use-default-transport-key --pin 1234 --puk 4321 --label "Teszt Elek keyring"

Törölni az eszköz teljes tartalmát:
$ pkcs15-init -E

Kiiratni az eszköz tartalmát:
$ pkcs15-tool --dump

PIN kód csere:
$ pkcs15-tool --change-pin

Az eszköz feloldása:
$ pkcs15-tool --unblock-pin

SSH:
----
Itt a legnagyobb problémát a Provider (opensc-pkcs11.so) megtalálása okozta, lehet más rendszereken máshol van, erre figyeljetek oda!

Létező ssh kulcs exportálása:

$ openssl rsa -in ~/.ssh/id_rsa -outform pem > id_rsa.pem

Majd felmásolása az eszközre:

$ pkcs15-init --store-private-key id_rsa.pem --auth-id 01

Belépés:

$ ssh -I /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so user@server

Eszköz hozzáadása ssh-hoz:

$ vim /etc/ssh/ssh_config
PKCS11Provider /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

VPN:
----
Itt is akadt egy hiányosság, mégpedig az, hogy a cinnamon GUI-ja nem támogatja ezt a fajta belépést, így egyelőre marad a konzol..

VPN kulcsok/tanúsítványok kiexportálása:

$ openssl pkcs12 -export -out key-file.pkcs12 -inkey privateKey.key -in certificate.crt -certfile CACert.crt

És felmásolása az eszközre:

$ pkcs15-init --store-private-key key-file.pkcs12 --format pkcs12 --auth-id 01

Ez egy fontos lépés!! Az itt megkapott ID-t kell beírni az .ovpn konfigba (pkcs11-id) !!

$ openvpn --show-pkcs11-ids /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

$ vim .openvpn/vpn.ovpn
pkcs11-providers /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'

# openvpn --config .openvpn/vpn.ovpn

Források:
---------
http://www.gooze.eu/
https://openvpn.net/index.php/open-source/documentation/howto.html#pkcs…

( Lacyc3 v | 2015. 08. 17., h – 21:49 )

Feliratkozom, és aki tud bevállt, jó alternatívát, amit még gyártanak & forgalmaznak ne tartsa magában. :)

Itt nincs, helyette erre van: http://www.ftsafe.com/product/epass/epass2003
Nem említik sehol, hogy nem gyártanák már. Itthoni cég is forgalmazza: http://www.sectoken.com/fips-usb-token-feitian-epass-2003

Körbeszaglászok dm-crypt ügyben, mert igen ígéretes lehet.

A gooze annyit mond, hogy késnek a kiszállítások és igyekszik úgy utolérni magát, hogy virtuálisan kinullázza a raktárkészletet. :)

( rpsoft v | 2015. 08. 21., p – 04:19 )

Hamár van ilyened, nem akarod röviden összefoglalni, hogy mire való, miért jó? Pl. mivel biztonságosabb, mint ha egy penrive-on hordom a kulcsom?

Itt egy egész jó angol összefoglaló: http://www.gooze.eu/howto/smartcard-quickstarter-guide/why-use-smartcar…

Persze azért leírom szívesen a tapasztalataimat:
Mire való?
- Kulcsok és tanúsítványok tárolására, de lehet rajta tárolni mezei szöveges állományokat is.

Miért jó? Miért biztonságosabb mint egy pendrive?
- Például azért, mert a privát kulcsokhoz, csak a pin kód megadásával férhetsz hozzá. Sőt, ha párszor elrontod, már csak a puk kóddal lehet feloldani.
- A másik előnye, hogy legalább olyan kényelmes, mint egy pendrive. Azon túl, hogy bedugtad a gépedbe, más dolgod nincs vele. Nyilván a pin kód megadásán kívül. (Abban az esetben, ha előtte már feltelepítettél mindent.)
- Ami még nagyon tetszik, hogy a kulcsok mindig nálad lehetnek, biztonságosan. Nem kell a gépeden tárolni őket.

Röviden talán ennyi.

( kroozo v | 2015. 08. 21., p – 18:36 )

ha már ilyen eszköz, akkor nem lenne jobb on board generált kulcsokat használni?

(mondjuk, hogy egyáltalán van dump, az pfejj)

dependson, ideális esetben megkérem mondjuk az idm-et, vagy a puppetet, vagy valamit hogy tegye szépen a helyére, kevésbé ideális esetben valahogy körbescriptelném. Van egy ssh-copy-id nevű cucc, amivel szerintem lehetne olyat csinálni, hogy a régi kulccsal belépkedsz (odaadod az ssh-agentnek), és ez meg hozzácsapja az újat. Listát, ha nincs, akkor pl egy known_hosts parzolgatásával lehet csinálni.

Aztán hegesztenék valami randát, ami már az új kulccsal kitakarítja a régit az authorized_keysből.

De nyilván, ymmw attól függően, hogy milyen a környezeted (a gyakorlatban én pl valószínű a securecrtmet scriptelném meg, vagy simán csak interaktívban dolgoznék sok ablakban, de nem hiszem, hogy azzel előrébb vagy, ezért gondoltam, hogy valami általánosabbat feltételezek)

Tudom. Márahol. A szomorú valóság meg pl. egy játszós vmen megnézve centosországban:

[root@centos7a ~]# uname -a
Linux centos7a 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@centos7a ~]# cat .ssh/known_hosts
localhost ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCiRqWp1vJVVjd2GUrZ4+yIRhevzGshUBJVeAP2xzh8UM+YcAdCHYYVAvTWVYjR0uEaAxDXVOnRBYFCI1xw/Tms=
192.168.1.100 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCiRqWp1vJVVjd2GUrZ4+yIRhevzGshUBJVeAP2xzh8UM+YcAdCHYYVAvTWVYjR0uEaAxDXVOnRBYFCI1xw/Tms=

Jo neked: 


|1|BYqmhIPdsfSYBV6rZOcBb+EouhE=|5LrqGQ19XCSQm6Za7W8bB1U8NIo= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMdkof9gon4Fuu6LEGUS3t0yPylFvkOxlErvoo79E0G4Fyq39+NHRrcGKYDM7pbyLC8GS90IIOAeWR9qbelY9Z4=
|1|5n6DgXZVMNyEoXJKUGNRfeK+U7c=|dtjdf4KcIHr9HxnQ99gIgO/cj64= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKlequzS+rIcKh8ufmEE4UArZj53dYqLa7h3oltqncx/dSg6BMKmLfbFKcrzwsEK6LnlbXPfQzlThYMntFQsxOQ=

--
Blog | @hron84
Üzemeltető macik

man ssh_config: 


     HashKnownHosts
             Indicates that ssh(1) should hash host names and addresses when they are added to ~/.ssh/known_hosts.  These hashed
             names may be used normally by ssh(1) and sshd(8), but they do not reveal identifying information should the file's
             contents be disclosed.  The default is “no”.

A debianosban viszont: 


 Note that the Debian openssh-client package sets several options as
     standard in /etc/ssh/ssh_config which are not the default in ssh(1):

           ·   SendEnv LANG LC_*
           ·   HashKnownHosts yes
           ·   GSSAPIAuthentication yes

Szóval ja, az opció ott van, de defaultból ki van kapcsolva, hacsak a disztribútor másképp nem dönt neked.

(szerk: és persze a debianos maintainer a már nem írta oda az opció leírásához, hogy a default is no, de megváltoztattuk, csak fent van egy notesz róla. :)