Mitől működik az eszemélyis email aláírás?

Közösségi kerekasztal

Sziasztok!

Idén megigényeltem én is az eszemélyit, de nem működik az email aláírás, minden más meg igen.
Linux alatt és Windows alatt is.
A certben szerepelnie kell valahol annak az email címnek, amiről aláírt levelet akarok küldeni?
Esetleg a Subject Alternative Name-ben?

  • 1558 megtekintés

( mauzi v | 2022. 02. 03., cs – 21:27 )

Szerkesztve: 2022. 02. 03., cs – 21:29

A certben szerepelnie kell valahol annak az email címnek, amiről aláírt levelet akarok küldeni?

Igen. Az e-személyi igénylésekor kell megadni az e-mail címet, illetőleg:

Az elektronikus aláírás és időbélyegzés szolgáltatás igénylésére korábban kizárólag az okmány igénylésével egy időben kerülhetett sor, felhívjuk szíves figyelmüket, hogy már lehetőségük van az e- Aláírás megújítására és utólagos igénylésére az okmányirodai és a kormányablak hálózat ügyfélszolgálatain.

tudták frissíteni

Ezt nehezen tudom ilyen formában értelmezni...
Ha e-mailt szeretnél aláírni, akkor kell, hogy legyen a tanúsítványban e-mail cím. Ha most nincs benne, akkor új tanúsítvány szükséges.

Az e-Személyiben van "e-mail cím" adatmező is, aminek semmi köze nincs az e-Aláírás funkcióhoz, meg a hozzá kapcsolódó tanúsítványhoz. Nem lehet, hogy csak ezt "frissítették"? Mi a tanúsítvány érvényességének kezdete? A "frissítés" időpontjánál korábbi?

( mauzi v | 2022. 02. 03., cs – 22:14 )

Szerkesztve: 2022. 02. 03., cs – 22:17

- nem ide -

( zeller | 2022. 02. 03., cs – 23:25 )

Hogyan szeretnél az e-személyivel aláírást létrehozni?

KEAASZ-szal PDF-et tudok aláírni, az működik.

Az eszig kliensben a tanúsítnány email mezője: nem elérhető.

Thunderbirdben S/MIME Personal certificate for digital signing: ide ki tudok választani egy bejegyzést, előtte kéri a 7 hegyű PIN kódot.

Levélküldés előtt beikszelem, hogy írja alá, az olvasó pislog és ezt írja:

Sending of the message failed. Unable to sign message. Please check that the certificates specified in Mail & Newsgroups Account Settings for this mail account are valid and trusted for mail.

( andras0602 | 2022. 02. 04., p – 00:36 )

Nekem benne van az email címem. Linuxon is be tudtam S/MIME-hoz a Thunderbird-ben állítani. Megjelenik a tansi, az email címem, Thunderbird felismeri stb. (de titkosítani nem engedne vele, csak aláírni).
Majd a levélküldésnél hibára fut. Szerintem a middleware-rel van a probléma.

A PDF aláírás  jól, de lassan működik ->  csak a hozzá készített szoftverrel (KEAESZ, amiben előre és koordinátákkal lehet csak megadni az aláírás helyét). Mással, pl. Adobe Readerrel nem működik. Itt is a middleware-t gondolom a kevésnek.

Szerintem a middleware jelenleg ennyit tud.

Ügyfélkapu belépés (a másik tansi, másik pin) Chrome-mal jól működik.

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

Szerintem azért nem tud titkositani, mert mivel smart card, át kellene lapátolni a modem sebességű rádiós kapcsolaton a teljes aláirandó adattartalmat, az pedig nem jó ötlet.

Ezért inkább csak a dokmunemtum/levél/akármi hash-e megy át, azt irja alá, igy lesz aláirva bármi, de nem titkositva.

Te is rosszul tudod, és amire válaszoltál, az is hibás.

Kulcspárral lehet aláírni is: a saját kulcspárod privát részével írsz alá, mások a publikus rész birtokában meggyőződhetnek róla, hogy csak te írhattad alá. Nem kell az egész adatmennyiséget átvinni a kártya chipjéhez, csak a hash-et.

Kulcspárral lehet titkosítani is: a címzett (több címzett esetén minden egyes címzetrte külön-külön) kulcspárának a publikus részével titkosítasz. Ezt elolvasni csak a címzett tudja a saját privát kulcsának birtokában. Nem kell az egész adatmennyiséget átvinni a kártya chipjéhez, hanem csak egy random generált rövid értéket. Ez a rövid érték lesz publikus/privát kulcsú algoritmussal titkosítva a kártya chipjével. A hosszú üzenet meg egy szimmetrikus algoritmussal, pl. AES lesz titkosítva, amelynek a kulcsa az előbb említett random generált rövid érték.

A kulcspár _aláírásra_ lett létrehozva, nem pedig _titkosításra_. A kettőt -bár sok esetben nem teszik- el kellene különíteni.

Ezt az állítást nem cáfolja az érved, miszerint az adott kulcspár technikailag alkalmas lenne aláírásra és titkosításra is, ugyanis az a tanúsítványban van meghatározva (RFC 5280), hogy a kiállító szabályai szerint az adott kulcspár milyen célra használható:

4.2.1.3.  Key Usage
4.2.1.12.  Extended Key Usage

Lent látható, hogy a X509v3 Key Usage értéke Non Repudiation, tehát ezzel a kulcspárral nem fogsz titkosítani egy olyan PKI-ban, ami az hatályos RFC-knek megfelelően működik.

De persze az RFC-k nem akadályoznak meg abban, hogy a kulcspárhoz közvetlenül hozzáférve adatokat titkosíthass vele, ha éppen úgy tartja az úri kedved. Nem vagyunk egyformák, vannak törvénytisztelők, törvényen kívülien, törvények felett állók, a pénztárnál, meg a dugóban sem várja ki mindenki a sorát, miért pont a PKI lenne kivétel, ahol betartják az emberek a szabályokat!? ;-)

Szabi

de titkosítani nem engedne vele, csak aláírni

A titkosítás úgy működik, hogy a címzett publikus kulcsával titkosítod a levelet, amit ő a privát kulcsa birtokában tud megnyitni. A titkosításhoz tehát nem neked kell tanúsítvány, hanem a címzettnek. Neked az ő publikus kulcsa kell.

Gondolj bele, neked van egy privát kulcsod, amivel titkosítanád a levelet. Mivel a publikus kulcsodat bárki birtokolhatja, bárki meg tudná nyitni a levelet. Akkor, az mitől lenne titkos? :)

A sajátoddal_is_ és az n+1 címzettével _is_ titkosítod a -mondjuk- AES-hez használt kulcsot, és azt rakod oda a titkosított adatok mellé - ekkor midnenki, aki rendelkezik az AES-hez használt kulcs titkosítására használt n+2 darab publikus titkosítókulcs privát párjával, ki fogja tudni nyerni az AES-hez használt küulcsot, és azzal ki fogja tudni nyitni az AES-sel titkosított tartalmat. (Úgy 2000 körül foglalkoztam legelőször ilyesmivel, igaz, az masszívan pgp-s megoldás volt, az elvi működés ugyanaz.)

Ha a feladó privát kulcsával titkosítod, akkor mindenki, aki rendelkezik a feladó publikus kulcsával az ki tudja csomagolni - és a publikus kulcs pont olyan, hogy bárkinek odaadható... :-P

Szóval titkosítani az érintettek publikus kulcsával, aláírni a feladó privát kulcsával, ha meg nem sértelek :-P

Mármint ha beírnák a cert-be, hogy key- és/vagy data-encryption, akkor se lenne az ECDSA-kulcsnak ilyen művelete. (Már amennyire visszaemlékszem így hirtelen az OpenSSL-doksikra. Szerk: egy ilyet találtam hirtelen: https://www.openssl.org/docs/man3.0/man1/openssl-pkeyutl.html )

( drobert82 | 2022. 02. 04., p – 10:33 )

A cert ilyen mezőket tartalmaz, hátha ebből látszik, hogy mi nincs

Using slot 0 with a present token (0x1)
Certificate
   Data
       Version
       Serial Number
       Signature Algorithm
       Issuer
       Validity
           Not Before
           Not After  
       Subject: C = HU, SN = , GN =  , serialNumber = , CN =  
       Subject Public Key Info
           Public Key Algorithm
               Public-Key
               pub
               ASN1 OID
               NIST CURVE
       X509v3 extensions
           Authority Information Access
               CA Issuers - URI
               OCSP - URI
           X509v3 Subject Key Identifier
               96
           X509v3 Basic Constraints
               CA
           X509v3 Authority Key Identifier
               keyid
           X509v3 Certificate Policies
               Policy
               Policy
                 CPS
                 User Notice
                   Explicit Text
           X509v3 CRL Distribution Points
               Full Name
                 URI
           X509v3 Key Usage
               Non Repudiation
           qcStatements
   Signature Algorithm
 

( Aadaam v | 2022. 02. 04., p – 15:03 )

Attól működik, hogy van egy eIDAS rendelet, ami szerint ezek legális aláírások.

mesélj, hol van az a helyzet, ahol egy kommersz eIDAS szolgáltató (pl. helloSign) aláírása nem jó, és neked muszáj az e-személyivel bohóckodnod?

Három rövid kérdés az alternatív javaslatoddal kapcsolatban:
-Mennyibe kerül
-Milyen szintű azonosítás van az aláírás mögött
-Milyen szintű védelme van a kulcspár titkos felének

Egyébként ha nem e-személyis "bohóckodás" (helyesen: jogszabályi környezetnek mindenben megfelelő elektronikusan aláírt, teljes bizonyító erejű magánokirat készítése elektronikus dokumentum formájában), akkor ott az AVDH, mint opció.

- A helloSign havi 3 dokumentumig ingyenes… ezt még a büdös életbe nem sikerült túllépnem.

- szerintem ő csak emailcímet kér, de lehet hogy be kellett mutatnom a személyimet, már nem emlékszem

- fogalmam nincs, meg kell nézni

mindenesetre az eIDAS rendelet rá is igaz, és ilyen marhaságokra, mint PhD munkaterv aláírása nekem tökéletesen megfelel. A vállalkozásban meg a tapasztalat az, hogy nem a szerződés a bizonyító erejű hard dolog, az csak egy papírmunka: a bizonyító erejű az a kiegyenlített, NAV adatbázisban szereplő számla.

ha én minden egyes ügyfél után rohangálnék aki az első részletet nem akarta kifizetni, akkor ezt űzném főállásban, szóval egyszerűbb egy ügyvédi munkadíjnyi első mérföldkövet csinálni, mint azt nézni, hogy melyik aláírásszolgáltatónak milyen hosszú és mennyire erős a hash-e…

( mraacz | 2022. 02. 04., p – 18:38 )

A TB-ben az S/MIME rovatban a postafiókhoz aláírási és titkosítási tanúsítványt is meg lehet adni. Még soha senkitől nem láttam, hogy ezt bárki be tudta volna állítani e-személyivel. Minden ezzel kapcsolatos kérdésre dől a hülyeség a pdf-ek, doc-ok hitelesítéséről, rendeletekről, kulcsokról stb. és a végén kapcsolódó ítéletek. Aki ért hozzá, az nem ismeri a TB-t, aki ismeri a TB-t az nem tudja beállítani. Sikerült ez már valakinek egyáltalán?

Ez nem is volt kerdeses.
Csak email akartam alairni, de emailt nem akartam titkositani.
Persze TB-ben S/MIME alatt kivalaszthato a cert ALAIRASHOZ, nem titkositashoz, ezt meg is teszem.
Kuldeskor pedig hibara fut, hogy nem talalhato az emailcimhez valo tanusitvany.
Gondoltam hatha listazom a certben kitoltott bejegyzeseket es majd ha valaki nagyon raer megnezni egy mukodo eszemelyit (koszonom elore is ha lesz ilyen), hatha kiderul melyik mezo hianyzik / nincs kitoltve.

1818 emailes levelezes nem celravezeto egyaltalan, azt kerdezik, hogy a driver fel van-e telepitve es hogy a laptopban levo SC olvasoval nem kompatibilis, azt vegyem ki, amikor eszemelyir hasznalom.

Most hogy így mondod, valóban emlékezni vélek, hogy amikor ilyesmivel kísérleteztem pár éve, arra jutottam, hogy a kártyában van a chip, a chipben van a certificate [meg a privát kulcs], a certben van az emailcím, és ha az nem azonos azzal, ami a feladó a Thunderbird-ben, akkor nem fog a TB aláírni ezzel a kulccsal.

Korábban említettem, hogy nekem benne van, de így sem működik Thunderbird-del az aláírás. Szerintem a middleware (eSzemelyi Kliens) ami kevesebbet tud, mint szükséges volna Linuxon. Be kéne tudnia kérni a PIN kódot az aláíráshoz a TB-nek és ez timeout-ol. Lehet, adok még neki egy próbát Windows-on is.
Tök jó téma volt, jó lett volna egy kis tapasztalatot cserélni, esetleg összehasonlítani a német, belga, észt megoldásokkal, illetve sikerült-e másnak másképp szóra bírni a kártyát.
De sajnos... szokás szerint elHUP-osodott az egész. :(

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

Mikor lejárt az esign érvényessége, már nem volt kedvem az ügyintézéshez, hogy legyen új, inkább sorsára hagytam. Kipróbáltam sima (szoftveres) privatekey+certificate párost is, de azt is meguntam néhány levél elküldése után. (Ebből az időből emlékszem arra a részletre, hogy az aláíráshoz jó az ECDSA kulcs, de a titkosításhoz csak az RSA.)

(Szerk: Reiner CyberJack olvasót használtam, az olcsóbb, billentyűzet nélküli fajtát. Linux alatt nem ment elsőre: https://hup.hu/node/162372 )

( nagysa v | 2022. 02. 21., h – 18:20 )

Szerkesztve: 2022. 02. 24., cs – 07:30

Nálam TB-ben így működik.

debian 11, az olvasó: 0c4b:9102 Reiner SCT Kartensysteme GmbH cyberJack RFID basis contactless smartcard reader

-
Postafiók beállításai --> Végpontok közötti titkosítás --> s/mime biztonsági eszközök betöltés
a modulname = eszig, de lehet bármi, Modul file neve = /usr/bin/eszig-pkcs11.so (ennek biztos itt a helye?)

-
Postafiók beállításai --> Végpontok közötti titkosítás --> s/mime tanusítványok kezelése --> saját tanusítványok kiválasztod a tanusítványodat --> megtekintés
ott Letöltés PEM (tanúsítvány)
majd megnyitod: openssl x509 -in nagy-sndor.pem -text és a CA Issuers sorban: http://cca.hiteles.gov.hu/cer/GOVCA-CCA.cer na ezt letöltöd.

-
A letöltött cer file-t a tanusítvány kezelőben importálod a hitelesítés szolgáltatók közé és nem felejted el kipipálni az email aláírás-ra használatot sem!

U.I.:
Néhány menüt fejből írtam.
Ha nem fut az eszemelyi Klens, akkor betölti és kéri a pin kódot.
Titkosítani nem tud.

nekem is hasonlo modon sikerult mac-es TB-ben beallitani, az alairas mukodik is. annyi fun fact, hogy a beallitas utan restartolni kellett, addig hibat dobott kuldeskor.

viszont az outlook hibasnak mutatja az alairast, gondolom hianyzik neki a CA.  ha a CA-t minden cimzettnek importalnia kell akkor ennek igy nincs tul sok ertelme :(

Igen igazad van teljes bizonyító erejű magánokiratot nem fogok  összerakni cacert-el. Ám ahogy az eszig ca úgy cacert ca sincs benne a böngészőkben (sem).
Az , hogy mi a bizonyító erejű tisztán politikai és üzleti kérdés, ezért erről nincs mit beszélni.

Mikor 10+éve elöször kaptam ilyen iratot vittem magammal a csr-t, hogy írják alá. Aztán kiderlült, hogy ez nem így van. Csak én nem ismerem a privát kulcsomat.
Persze utólag beláttam ez így (hogy te viszed a csr-t) kivitelezhetetlen. Az átlag ember azt sem tudja, hogy mi az a csr.

( zeller | 2022. 02. 24., cs – 01:14 )

Szerkesztve: 2022. 02. 24., cs – 01:14

nemide.