Il 03/10/2012 13:23, Anders Rundgren ha scritto:
What do you decipher from the following?
http://lists.w3.org/Archives/Public/public-sysapps/2012Jun/0058.html
That Gemalto is interested in being an early player? :)
BYtE,
Diego.
___
opensc-devel
Il 29/09/2012 09:01, Frank Cusack ha scritto:
I knew something that didn't need trusted software (in the PC) should
exist. And Finally I found it:
http://www.ftsafe.com/product/epass/interpass
Seems quite near to my idea of a really-smart card: big display to
show
Il 23/09/2012 12:04, Andreas Jellinghaus ha scritto:
In my mind, the SE should take over display and touch controller by
hardware means, so absolutely no app can snoop user input or fake it.
Too bad seems nobody really *needs* that level of security...
The problem with that
Il 25/09/2012 07:58, Andreas Jellinghaus ha scritto:
EMV for sure: there's an unauthenticated bit that tells the card to
authenticate the transaction without asking for the PIN...
Thats ok, it is a valid feature. If people buy something for less than a
dollar, and the transaction is
Il 25/09/2012 11:50, Peter Stuge ha scritto:
IIUC that bit is not authenticated, so a MITM attack can force both the
reader and the card think the other party doesn't support PIN auth,
making the card sign the transaction anyway, regardless the amount
involved. So IMVHO it's quite serious...
Il 22/09/2012 19:37, Anders Rundgren ha scritto:
In my mind, the SE should take over display and touch controller by
hardware means, so absolutely no app can snoop user input or fake it.
Too bad seems nobody really *needs* that level of security...
The problem with that is that is impossible
Il 23/09/2012 11:52, Andreas Jellinghaus ha scritto:
In my mind, the SE should take over display and touch controller by
hardware means, so absolutely no app can snoop user input or fake it.
Too bad seems nobody really *needs* that level of security...
like credsticks from scifi novels
Il 24/09/2012 21:37, Andreas Jellinghaus ha scritto:
no, I was refering to all the magic solutions that make things secure
suddenly.
there was a good comic strip I can't find just now...
Hackers view: oh, no, this laptop is protected by 4096-bit RSA... no way
we can recover it even with
Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto:
In my mind keys could optionally contain application-oriented ACL
telling which
applications they trust so that even if you install a bad App, it
would for
example not be able to use your bank or eID-key in the
Il 05/09/2012 13:29, helpcrypto helpcrypto ha scritto:
The most advanced i have seen here so far is 2048 :P
I bought (but haven't yet had time to experiment with) Cryptomate64:
http://www.acs.com.hk/index.php?pid=productprod_sections=0id=CRYPTOMATE64
See my message dated 2012/05/23.
Doesn't
Il 19/08/2012 10:14, Anders Rundgren ha scritto:
Virtual smart cards have unlimited capacity and doesn't occupy space in
your pocket either.
Then an USB token paired with some form of unsecure storage and have
RSA capabilities and a button or a small keypad (display w/
touchscreen?) to enter
Il 19/08/2012 15:50, Anders Rundgren ha scritto:
Everything you write is fine and probably correct as well.
The only fly in the soup is that *it is not happening*.
I think it will be just like the TPM: when enough people will realize
what it is, it won't get accepted by the public.
It's not
Il 06/08/2012 10:15, Andreas Schwier ha scritto:
the name's just a name ;-)
Probably he (like me) hoped it was something more like (would-be)
MicroCA: a card taking a CSR and outputting a cert if constraints are
satisfied...
BYtE,
Diego.
___
Il 23/07/2012 08:49, helpcrypto helpcrypto ha scritto:
IIRC, C_Login can accept user type CKU_SO to login as admin, the
problem might be what you could do as admin. Probably that depends
on the card.
The problem with FF (and TB) is that it calls C_login only once, then
assumes the login is
On 30/05/2012 11:42, Alon Bar-Lev wrote:
PKCS#11 is weak in term of privileges, not always it is possible to
access the complete feature set via this interface without proprietary
extensions.
IIRC, that's why profiles are needed when you use the card, not only
when you initialize it, right?
Il 25/05/2012 10:59, Martin Paljak ha scritto:
Hello,
On Wed, May 23, 2012 at 2:57 PM, NdK ndk.cla...@gmail.com wrote:
I'm thinking to use one to store our internal root CA's key (4096bit
RSA). [actually I'm thinking more about a ring of roots, but that's
another story]
Care to share
Il 25/05/2012 11:51, Aventra - Hannu Honkanen ha scritto:
ACR122U reader gives a different ATR than a contact reader for the same dual
interface card but otherwise the reader works just like a contact reader
with PKI cards. If you force usage of the myeid driver, it should work.
Perfect. I'll
Hi all.
Just received $subj and started testing.
Too bad the cards aren't recognized by default:
$ opensc-tool -a -n
Using reader with a card: ACS ACR122U PICC Interface 00 00
3b:85:80:01:4d:79:45:49:44:78
Unsupported card
Is it only matter of unknown ATR and I can safely use force myeid? Or
On 24/05/2012 15:39, Martin Paljak wrote:
Too bad the cards aren't recognized by default:
$ opensc-tool -a -n
Using reader with a card: ACS ACR122U PICC Interface 00 00
3b:85:80:01:4d:79:45:49:44:78
Unsupported card
I'm not certain about all ACS products, but one of the 122 reader
marketed
On 24/05/2012 17:56, NdK wrote:
Found some docs. Actually the reader's docs from ACS, that seems really
well-written (API_ACR122U_v2.01).
BTW for the other ATR
(3b:8f:80:01:80:4f:0c:a0:00:00:03:06:03:00:01:00:00:00:00:6a)
I already found: it's a Mifare One card (just tested with others I had
On 24/05/2012 18:33, Ludovic Rousseau wrote:
ACS forked my CCID driver. I got no contract with ACS.
Argh!
Your ACS ACR122U PICC Interface reader should work with my CCID driver.
Seems so. Might be useful to look at the differences?
BYtE,
Diego.
___
Hello all.
Someone already tested that token? It's the only one I could find that
handles RSA4096...
http://www.acs.com.hk/index.php?pid=productprod_sections=0id=CRYPTOMATE64
I'm thinking to use one to store our internal root CA's key (4096bit
RSA). [actually I'm thinking more about a ring of
On 23/05/2012 20:18, Peter Koch wrote:
Someone already tested that token? It's the only one I could find that
handles RSA4096...
So does the OpenPGP card and the CryptoStick (which contains that card)
I evaluated it, but it's *currently* usable only from GPG.
And the info I found said
On 23/05/2012 15:12, Joemar Mante wrote:
I have worked with ACS before handling products related to ACOS5/ACOS5
64K. Though we have not any test with open-sc using this particular
card.
So the only way is to buy it and try...
Worst case: about 50€ wasted. Best case: a good token.
In the worst
Il 22/05/2012 14:32, Martin Paljak ha scritto:
Regarding PIN codes, communication is protected with AES, in addition
to BT pairing.
How does the AES key exchange work? 'cause it's the weak link...
If the attacker can obtain the AES key (for example if it's printed on
the unit and the attacker
Il 21/05/2012 14:11, helpcrypto helpcrypto ha scritto:
http://ubertooth.sourceforge.net/ about ~100 EUR including shipping.
how do you insert the smartcard there?...and how to connect it to the
android/iphone?
You don't. It's useful to mount an attack against any BT sc reader (if
sc doesn't
Il 26/04/2012 11:32, helpcrypto helpcrypto ha scritto:
and, what if i edit your current config and replace the lib with my
modified evil lib?
And what if I replace the trusted reader w/ another, hacked?
Not too hard, it seems, since many supermarkets got hacked this way...
The only really
Il 26/04/2012 12:22, helpcrypto helpcrypto ha scritto:
If you can edit a root file you can do anything much more evil.
having root acces having pin = using private key
Just install a keylogger (maybe an HW one on the PS/2 cable? I've seen
one that is quite hard to recognize... or even one
On 23/03/2012 19:10, Peter Stuge wrote:
The problem is not that the code can not be reviewed, but that noone
is doing review. Anyone can do it.
I'd do reviews, but the last time I tried to really understand OpenSC's
flow, all I got was an headache (a big one...) :(
So it's not a will issue,
Il 21/03/2012 11:27, Szabó Áron ha scritto:
What is the maximum number (if any exists at this level) of regular smart
cards, USB tokens (and keys) that can be used and managed by OpenSC in the
same environment (USB controller supports up to 127 devices, up to seven
tiers, including the
Il 19/01/2012 09:16, Peter Stuge ha scritto:
Christian Hohnstaedt wrote:
Anything that can be signed by the card can be signed by a software
key, too.
Yes of course. But the point is that the card can come with the
special key pre-installed.
I see at least two ways here:
1) the 'technical'
Il 16/01/2012 07:29, Scott Thomas ha scritto:
I am using Cryptoflex e-gate v4 32k card which contains 8 slots for
certificates. I have tried slot0-id_45 to slot7-id_45.
On slot 0 it works fine but from slot 1-7 it gives error of empty slot
which means that other 7 slots will must work fine
Hi all.
Being on vacation I could finally resume my experiments.
But I noticed that lastly every command is sluggish.
Running pcscd -f -d I could pin down the slow op to the SCardConnect:
0028 Card ATR: 3B F5 18 00 00 81 31 FE 45 4D 79 45 49 44 9A
0007 winscard.c:328:SCardConnect()
On 21/12/2011 19:59, Peter Stuge wrote:
NdK wrote:
But I noticed that lastly every command is sluggish.
..
Is there something I should check or some more debugging I should enable?
Probably libusb bug #56 which has been fixed but not available
everywhere just yet. What distribution do you
On 23/11/2011 22:44, Douglas E. Engert wrote:
javax.smartcardio.* = Total crap IMNSHO.
IMVHO: Java and smartcards don't work really well together...
Does this help:
http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunPCSCProvider
The system property
Il 09/11/2011 18:39, Viktor Tarasov ha scritto:
I would like to 'touch' the PKCS#11 module of OpenSC and looking for your
opinions/suggestions about:
Regarding touches... Is some level of restructuration planned?
I'm thinking about something object-oriented, a-la GTK+ (OO C, not C++).
I'm
Il 14/10/2011 08:11, Anders Rundgren ha scritto:
http://www.ecsec.de/pub/2007_TrustBus.pdf
http://openidtrustbearer.wordpress.com/2009/12/11/first-impressions-of-isoiec-24727
Is this for real?
Seems so.
Maybe could even help opensc: many card drivers could be grouped as one.
The resulting
On 14/10/2011 12:34, Tomas Gustavsson wrote:
There was still mentioning about smart card middleware in the article. I
didn't quite get it, but anything that still requires installation of
different middle-wares for different cards does not bring us much closer
to a token enabled world imho.
On 09/09/2011 21:22, Douglas E. Engert wrote:
One possible way would be to turn off some drivers
in the opensc.conf file. Comments and an OpenSC web
page would say how to turn it back on, and how to request
that it not be dropped.
The only way that works: break it in a way that requires user
On 09/08/2011 20:48, Vlastimil Pavicek wrote:
I haven't read the whole thread, but you might find this library useful (it
is easier to use than JNI/JNA):
http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/PKCS-11-Wrapper
Tks.
Found last night. It's used by j4sign[1] that targets
Il 03/08/2011 09:32, helpcrypto helpcrypto ha scritto:
Do yo code on assembly for you web pages? PCSC should be used only
if your smartcard doesnt have a higher level of abstraction possible
(like opensc)
I'd even prefer higher APIs, since doing security really well is hard.
I usually do C,
Il 03/08/2011 11:08, helpcrypto helpcrypto ha scritto:
As i understand, you want to develop like a wallte, where password
stored on server (crypted) are copied to clipboard (altough a simply
CTRL+V will display it), to let the user authenticate in toher
services. Right?
Yup. Right. Ctrl-V is
Il 03/08/2011 13:35, helpcrypto helpcrypto ha scritto:
And (more general question) why a slot identifies a pin? What about
insecure keys and their certs? See below.
An slot doesnt need to have a PIN, as stated on PKCS#11 standard.
Then why I get *exaxtly* one slot per PIN (and in the slot name
On 03/08/2011 16:16, Douglas E. Engert wrote:
You say you are using FF, so have you looked at JSS?
http://www.mozilla.org/projects/security/pki/jss/
Nope. Proprietary (available only for FF).
As I read this, it is a java interface to NSS, and thus avoid the
sunPKCS11 and its limitations, but
On 03/08/2011 19:40, helpcrypto helpcrypto wrote:
Well... The user should be responsible for selecting the best slot.
That IMHO shouldn't be a slot in the first place, but just a
certificate. The browser should only filter certs so that only
acceptable ones are proposed to the user.
Thats
On 03/08/2011 21:25, Martin Paljak wrote:
And what about smartphones? Standard Java is more likely to be adapted
than proprietary interfaces.
I don't believe that current smartphone platform vendors will embrace PKCS#11
as we know it on the desktop. At least I hope they will not. It would
Hi all!
Maybe it's nearly OT, but I think it could be useful for other readers.
I've found that a quite recurring problem in accessing tokens from java
is the PKCS11 not found exception.
Disabling hot plug support, as suggested in the past to another user,
didn't work in my case.
The
On 02/08/2011 16:22, Felipe Blauth wrote:
Java Cryptographic is based on JCA/JCE arquitecture. The document at
http://download.oracle.com/javase/1.5.0/docs/guide/security/p11guide.html ,
preety much explains everything you need to know.
I'll have to reread it.
It says, for example,
that
On 06/05/2011 21:23, Juan Antonio Martinez wrote:
Sure: there are some cases where these approach fails:
SSL renegotiation when signing applet is running; two pkcs11
trying concurrent access to the card... but this is not
as usual as thought.
IMHO you could avoid troubles using a simple state
On 25/04/2011 11:01, Viktor TARASOV wrote:
For what I've understood, -a N makes $PIN in profile be replaced by
CHVN, hence IMO --insecure= $PIN-NONE.
No,
'-a N' means in fact '-a ID of authentication object .
The real PIN reference, the one that can be used in the PINs APDU,
is extracted
On 27/04/2011 09:15, jons...@terra.es wrote:
BTW: I'm not sure of OpenSSH pkcs11 way to retrieve keys: afaik extract
it from certificates, but not sure if also handles
keys found in pukdf ¿anyone knows?
In my tests, OpenSSH used public keys from pukdf, not from certs (I
tested only with keys
Il 26/04/2011 08:41, Martin Paljak ha scritto:
Personally, I'm ready to remove at all 'insecure' option -- never used it.
All the stuff can be defined in the card profile. But let us wait for the
other opinions.
I've used it and I find it a generally useful option, for cases where
the card
Il 26/04/2011 12:41, Anders Rundgren ha scritto:
I don't know what you had in mind with an USB P11 token
but in case you would like to participate in an effort
making sort of a USB P11 token there is already a project
to dig in to:
http://webpki.org/auth-token-4-the-cloud.html
Interesting.
On 26/04/2011 18:51, Frank Morgner wrote:
You forgot to mention Virtual Smart Card Architecture
Already seen that, but always wrappers wrapped in other wrappers :(
The architecture can be greatly simplified: no need for APDUs
encoding/decoding, no need to handle card insertion/extraction, no
On 26/04/2011 15:19, Alon Bar-Lev wrote:
Just wanted to note that exposing such device to IP stack makes it a
target to hack,
That's why I'm quite reluctant to enable Ethernet port on such a dongle.
packaging is much more difficult.
I don't want to compete with $20k HSM. They use dedicated HW
On 26/04/2011 19:16, Anders Rundgren wrote:
As far as I know not a single HSM (even those who cost $20 000)
out there is able to certify that keys actually were created
inside of the HSM!!! A $10-$20 SKS always attests the origin
of created keys using a built-in device key and certificate.
On 25/04/2011 14:33, jons...@terra.es wrote:
I can figure out at least these different popups:
[...]
7 - You'are about to emit a digital signature. Please confirm operation
And, anyway, you expose yourself to malicious apps that ask for a crypto
pin and use it to sign a document... As long
On 24/04/2011 13:17, Viktor TARASOV wrote:
The using of SC_PKCS15INIT_MAX_OPTIONS is not appropriate in this context.
SC_PKCS15INIT_MAX_OPTIONS is the number of profile options that can be defined
as an argument for the pkcs15init operations .
So I can use up to 16 +'option' ? :)
If you
On 24/04/2011 14:18, Viktor TARASOV wrote:
It seems the root of the problem lies in the profile: changing
CRYPTO=$PIN to CRYPTO=NONE works around it, but it's surely sub-optimal.
What I wanted to say: shouldn't --insecure replace $PIN with NONE ?
For what I've understood, -a N makes $PIN in
Hello all.
Since Toni can't look at this issue soon, I'm trying to fix it myself.
The problem is that, at least with Aventra MyEID, every key gets created
in a way that requires CHV1 for crypto ops, even if --insecure is specified.
It seems the root of the problem lies in the profile: changing
Il 20/04/2011 22:24, Frank Morgner ha scritto:
But all other functions of libopensc require the caller to allocate
enough space.
Vital for maintainable software: who needs memory, allocates (*and
frees*) it. As a sage said a long time ago: or you rewrite your project
this way, or your project
On 05/04/2011 20:58, Frank Morgner wrote:
My previous remarks in this mail apply to the inner structure of the SM
module. I consider your layout as the most promising. (Maybe because I
implemented something similar ;-) ) Beyond that what I have already said
about where to trigger SM, I have
NdK card
pkcs15-init -P -a 1 --pin $PIN1 --puk $PUK1 --so-pin $SOPIN -l Card Auth
#pkcs15-init -P -a 2 --pin $PIN2 --puk $PUK2 --so-pin $SOPIN -l User Auth
pkcs15-init -F
pkcs15-init -G rsa/2048 --insecure --id 1000 -u digitalSignature -l
SSH:ndk --pin $PIN1
-8--
In this scenario ssh works
,keyEncipherment,dataEncipherment,keyAgreement,keyCertSign,cRLSign
pkcs15-init -G rsa/$size $auth --id $2 -u $keyuse -l $3 --pin $PIN1
k=`pkcs15-tool --read-ssh-key $2 2/dev/null |tail -1`
echo $k $3
}
pkcs15-init -E -l NdK card
pkcs15-init -C --pin --puk --so-pin $SOPIN --so-puk
Hi all.
Could it be possible to check the available space on card files before
importing PKCS12 certs? Or at least rollback already done additions.
Now it could easily happen that a cert is only partially stored, since
the private key goes first, then every cert in the chain.
So after an import
On 23/02/2011 21:19, Martin Paljak wrote:
Enter PIN for 'MyEID (User Auth)':
C_Sign failed: 257
This means: #define CKR_USER_NOT_LOGGED_IN(0x101UL)
Having OpenSC debug.log would be useful - is the right PIN verified before as
it should be.
I tried to enable debug.log,
Il 23/02/2011 20:04, NdK ha scritto:
Extracted from pcscd log (just masked PIN):
-8--
openct/proto-t1.c:350:t1_transceive()
SW: 90 00
winscard_msg_srv.c:317:SHMProcessEventsContext() command TRANSMIT
received by client 11
winscard.c:1651:SCardTransmit() Send Protocol: T=1
APDU: 00 2A 9E 9A 23 30
On 19/02/2011 10:52, Martin Paljak wrote:
Unfortunately engine_pkcs11 (and OpenSSL in general) is not the best
interface for smart cards, especially for user interaction purposes. But a
patch against engine_pkcs11 might make the prompt a bit easier to understand
[1]
But it's good for
Hello.
I'm always the one that finds problems :)
Waiting to fix CA issue, I'm trying to use an on-card key to
authenticate a SSH user.
Key is there, and should have all needed flags set (generated w/ -u
sign,decrypt since IIUC ssh requires both):
-8--
Private RSA Key [SSH: ndk]
Object
On 23/02/2011 16:57, Peter Stuge wrote:
Even an strace didn't help locating the lib that can't be loaded.
Was that strace -fF ?
No. I'll try tomorrow to be consistent (on the same machine).
But could reproduce on this one too.
The only failing open is the one related to libgost.so .
If I:
ln
On 23/02/2011 21:19, Martin Paljak wrote:
Waiting to fix CA issue, I'm trying to use an on-card key to
authenticate a SSH user.
Which issue?
http://www.opensc-project.org/pipermail/opensc-devel/2011-February/016065.html
Seemed unrelated, but...
But when I try to use it, I get:
-8--
$ ssh
On 21/02/2011 14:03, Christian Hohnstaedt wrote:
XCA 0.8.x used the engine_pkcs11.
Ok. In Mandriva I had only 0.8.1 rpm.
In version 0.9.0, I dropped the need of engine_pkcs11 and use the
signing routines of the pkcs11 lib directly. Mainly to support multiple
PKCS11 provider in parallel.
So
On 22/02/2011 13:56, Toni Sjoblom - Aventra wrote:
The private key files sizes are shown in bits not bytes. A 1K private key
uses approx. 960 bytes and 2K respectively approx. 1296 bytes. This consists
of both the private and public parts.
This matches my experimental numbers better :)
28548
On 22/02/2011 15:41, Toni Sjoblom - Aventra wrote:
Sorry, the public key size for the 2K was missing from that value. That
explains the 320 bytes difference.
Public key file for a 2K bit key is 270 bytes. Also, some space is occupied
when new files are added as well.
Ok.
So 32 2048bit
On 19/02/2011 10:52, Martin Paljak wrote:
XCA worked with OpenSC quite OK IIRC, you might want to try it as well.
Done. All I get from XCA, when loading /usr/lib/opensc-pkcs11.so is:
-8--
The following error occured:
Successfully loaded PKCS#11 library: /usr/lib/opensc-pkcs11.so
SUCCESS:
Il 18/02/2011 07:07, Martin Paljak ha scritto:
Yup. That's why keys are generated on card :)
Unless the key is exportable
Always asked why one needs to mark a private key exportable: if you need
it exportable, create it externally and load to card. It's even faster. :)
If you want to
On 18/02/2011 10:54, NdK wrote:
*But* if I specify a slot too, it asks me for a PIN. Too bad *none* of
the PINs I created works:
$ openssl req -days 3650 -new -out rootca.csshl.org.csr -config
openssl.conf -engine pkcs11 -keyform engine -key 1:10 -sha1
Today openssl refusess to load engine
Hi all.
I'm now looking at another issue.
Having stored enough certs on card, I'm now trying to push it to the
limit.
Seems that openssh can't be told which key to use, but that's not OpenSC
related (unless someone here knows how to do it). So falling back to
pam_pkcs11 and CA handling.
I've
On 17/02/2011 22:55, Andreas Jellinghaus wrote:
no, that wiki page is correct and works for me - done it a hundred times.
it uses the key on the card, and the card does the signature (you cannot
read the private key, a smart card won't ever give it to you).
Yup. That's why keys are generated
On 16/02/2011 21:13, Martin Paljak wrote:
The same can be done for 768bit key, and, I suppose, for all key sizes from
512 to 2048 with the 64 bit step.
The only questions is: are you sure you want to do this? Small RSA keys are
often used in low profile hardware, where the smaller
On 16/02/2011 21:59, Martin Paljak wrote:
I would not date to suggest turning1024 key support off (which is the
recommendation by several organizations) but giving a nice fat warning to
the user when creating keys (not importing!) below 1024 (or 1024 keys when
the card claims support for
Il 15/02/2011 11:17, Toni Sjoblom - Aventra ha scritto:
Hi,
Woa. *That's* customer support!
Current MyEID cards are 80K, but some of this space is used by the MyEID
applet itself.
Ok. I'm starting to understand.
The file size you see in the 3F00 file is the remaining free space, but due
to
On 15/02/2011 16:47, Viktor TARASOV wrote:
Ok. So, 'limiting' to 32 keys (due to said limit in pkcs15-tool), I
could have:
cdf_size = 8640 # 3 * 32 * 90 (an average of 3 keys in every cert)
You mean 3 certs for each key?
I think that it's difficult to generalize this relation, the
On 15/02/2011 17:26, Viktor TARASOV wrote:
As for me, more appropriate solution is to define in your card profile some
section like 'option my_macros { macros { ... }}',
after (or instead of) the section 'option onepin' (to overwrite the existing
macro value),
and then to use something
On 15/02/2011 19:47, Viktor TARASOV wrote:
Sorry, this card can generate key 512bit .
For that the corresponding algorithm should be added to the list of the
card's algorithms.
--- src/libopensc/card-myeid.c (révision 5194)
+++ src/libopensc/card-myeid.c (copie de travail)
@@ -100,6
Il 14/02/2011 07:15, Martin Paljak ha scritto:
$ pkcs15-init -S startssl.p12 -f PKCS12 -i 45 -a 2 -l StartSSL auth
Using reader with a card: Gemalto GemPC Twin 00 00
error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure
Is this error normal? Does it happen with OpenSSL command line
On 14/02/2011 17:52, Andreas Jellinghaus wrote:
I have no clue about myeid, but some other cards are only 32k for example.
reserving 8192 would be 25% and that is only one directory file...
Well, javacards have a limit of 32k of data, IIUC, so it's more or less
the maximum for single-app
Certificate
Signing/CN=StartCom Certification Authority
2: /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Class 1 Primary Intermediate Client CA
User PIN [Card Auth] required.
Please enter User PIN [Card Auth]:
$ pkcs15-init -S ndk2.p12 -f PKCS12 -i 45 -a 2 -l ndk 2
Using
On 13/02/2011 14:38, Andreas Jellinghaus wrote:
yes, smart cards are quite old technology, files can't grow on demand :(
I knew that.
sorry, I know ono way to calculate such file sizes. all you can do is try and
error.
Yup. Hard to predict correct size, since certs can be of different size.
the 45 and 46 come
from. What is your source?
I read it somewhere while researching, noted it in my mind and forgot
source :(
Private RSA Key [StartSSL auth]
ID : 45
Private RSA Key [ndk@]
ID : 45
The software should not allow you to create
Hi all.
I'm using a MyEID card (got a pack of 5 to test) on a GemPlus USB-SW
reader. OpenSC is 0.12, from Mandriva Cooker (2011alpha) packages.
If I init the card and load a single certificate (actually the one I use
to authenticate on StartSSL.com) it's OK.
I can even generate a 2048 bit key
91 matches
Mail list logo
