Re: MUSCLE Disk encryption and more
On Fri, Jun 22, 2001 at 10:00:35PM +0200, Patrick Valsecchi wrote: The user will be able to change the code, that's not the matter, but it wont be able to run it on my customer's hardware. That's the point. And I don't this it goes against any law neither any license. I'm sure it doesn't go against any GPL spirit. It's even possible that my source will be partly available. It depends on the customer. But for the modified kernel parts, I'll have to publish it or I'll go against the Linux licence. For the CRC stuff, it was what I meant. Aren't CRC algorithms easy to reverse? So an attacker could generate his own program and simply add some bogus code at the end that'll make the CRC come out the same as an existing program... then steal the signed CRC from the approved program and use it. A keyed cryptographic hash (i.e. HMAC) would be more secure. But slower than CRC. Sha-1 or RIPEMD-160 in hardware might speed that up. If you use the smartcard to verify the kernel's signature, the kernel could then verify the signatures of programs instead of sending them all (or just their signed CRCs) to the smartcard. Since smartcards are slow, this would speed up loading. Tivo does something similar (linux that end-users aren't supposed to play with), you might check out what people are saying about them. Eric *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE
On Sat, May 27, 2000 at 01:42:29PM +0200, Harald Vogt wrote: On Fre, 26 Mai 2000, Jim Rees wrote: Another problem is that you really don't want (or at least I don't want) the card to be present in the reader during the entire session. I want to insert the card, have it log me in, then remove the card. Now I stay logged in until I log out, either explicitly or by timeout. That means the card Why don't you like your card being present during the session? If you pull out the card, you get logged out -- why not? You might need the card reader for something else. You might walk away and leave the card in the reader. If you're running *inux, you might leave your login session going for days (or months like me). -- Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5 *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE
On Sat, May 27, 2000 at 11:19:44AM -0500, David Corcoran wrote: I think Jim is concerned with having the card present and having a hacker maliciously query the smartcard subsystem for information. With the card removed this is not possible. That can happen no matter what- the attacker can install s/w that waits for card insertion, grabs the connection to the card before the legitimate s/w does, and then has it's way with it. This is a danger unless you have a smart card reader with a PIN pad and a display and the right sort of API interface. I wrote a paper on a design for such a secure reader: http://slack.lne.com/ericm/nable-threat-model.html Fortunately (sort of) with the PAM login, the security model doesn't need to protect you against this sort of attack, because the smartcard login is only to prevent unauthorized access to your host. You have already lost when the attacker can put the card snooping s/w on your host. This is not true of say a banking application. -- Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5 *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE
On Sat, May 27, 2000 at 09:49:16AM -0700, Eric Murray wrote: I wrote a paper on a design for such a secure reader: http://slack.lne.com/ericm/nable-threat-model.html oops, that should be http://www.lne.com/ericm/nable-threat-model.html -- Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5 *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE information
On Sat, Mar 04, 2000 at 09:40:03AM +0100, Josep Maria Carné Barnaus wrote: Hi all, I am looking for information about the process of generating keys - the private and the public key - in a smartcard. Someone told me that some types of smartcards needed a Security Access Module. Can anyone confirm this?. Is absolutely necesary use this module to create the pair of keys?. In some smartcards I think that it´s possible to create without this module. Particulary I am interested in Schumlberger, Bull, GyD, Gemplus The SAM I have heard of is a tamper-resistant (i.e. FIPS 140 or ITSEC) box which goes into ATMs. I'm not sure what a SAM for a smartcard means... maybe a box which is a reader and which generates the key to put it on the card? A number of higher-end smartcards have key generation facilities. One problem is that key generation for RSA requires a good source of random numbers, and I have heard from some researchers that smartcard RNGs are often poor. Hardware RNGs are wierd and often require a lot of power (i.e. for free-running ring oscilators) making them difficult to include on a space and power limited smartcard. I beleive that Gemplus GPK series cards can generate RSA keys. -- Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5 *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE PIN pad readers?
On Mon, Feb 21, 2000 at 03:17:09PM -0500, Jim Rees wrote: Can anyone recommend a reader with integrated PIN pad for use with Muscle pc/sc? Are there any that are supported, or at least have the necessary technical specs available? Compaq "secure smartcard reader". It supports PC/SC and also a couple extra PC/SC commands to do secure PIN entry on the PIN-pad or keyboard. -- Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5 *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Export Restrictions
On Sat, Jan 01, 2000 at 11:16:27AM +0200, Levi Eliav wrote: Hi, I have heard that the new Clinton administration eased the export restrictions in regarding to encryption products. Can some here (from the US) can check this issue ? They haven't yet. They promised to do so about 6 months ago, but when the proposed regs were released about a month ago, they wernt' all that much better than what we had previously. The administration is going to make some mods to those proposed regs and then see if they will be accepted. Bert-Japp Koops's Crypto Law Survey web page is the place to go to monitor crypto laws- he keeps it up to date. http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm -- Eric Murray www.lne.com/ericm ericm at the site lne.com PGP keyid:E03F65E5 *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Can I distinguish real SC hardware from an emulator?
n Fri, mep 03, 1999 at 08:00:40PM +0100, Peter Lister wrote: I'm thinking here about iButtons in particular, but the question is valid for all authentication tokens, smart cards, etc. Sorry if it's off-topic by not being Linux specific, but I've yet to find an answer anywhere. Assuming that I do *not* have control of the hardware into which my SC is currently plugged via a reader, how can a program (which, e.g. we have licensed to a client) be sure that it is talking to the genuine SC, and not an emulator? I really don't care how well tamper proofed the chip is if, or if it self destructs after 30 days free trial, if I can simply reproduce an unlimited number of copies in software which will have the same supposedly "unique" serial number, or have electronic wallets permanently charged up with credit which never decrements. Anything that passes along the serial interface can be intercepted and replayed, right? Right. Although you can use the usual cryptographic techniques to prevent replay and to prevent a snooper from listening in to the RS232 traffic. You might need a higher-capability card or a programmable card (i.e. Javacard) although the GPK4000 does have a DES-based protection for the traffic. One answer is if a crypto based key system generates an asymmetric key pair internally, and never reveals the private key or allows it to be set I understand that the crypto Java iButton will does this). Many smart cards will do this, although the RNGs on smart cards (used to generating the keys) is sometimes suspect. If the only traffic out of the SC is signed responses by that key pair and all the critical logic is internal, then any traffic on the serial line is only useful exactly once, which defeats replays. The software must contain code that checks for the smart card (and cannot easily by bypassed, which is an art in itself) - and this will be identical for all instances of the code. But even if the private key never leaves the SC, the corresponding public key must be stored *somewhere*, essentially in clear, though possibly obfuscated, and will be different for each different SC - and clearly any difference between otherwise identical distributions essentially *is* the key, and can be replaced with something else that an emulator would happily accept; back to square one. I do appreciate that I'm being really *quite* paranoid here, and that almost anything represents an improvement over current ways of doing things - essentially nothing. Can come up with characteristics which would be hard to beat, or is this a fundamentally insoluble problem? It's impossible to make this 100% secure. The assumption that you make is that the host can't be secured. This is true with Linux or any other OS (execpting Orange Book type B1 or better OSs). So, even with a perfect protocol between card and host, the protocol can be attacked on the host side by running the communications program through SoftICE or gdb or whatever to find it's secrets. One solution is to fix your system so that host-based attacks don't break the security model. I.e. the host is in a steel box with only a network connection and smartcard slot to communicate with the outside world. Problem is, this isn't very useful (and someone could still break in via the net connection). Or you can apply the usual software protection tricks (obfuscating code, checking for being stepped in a debugger, etc) to your software which authenticates the smart card and hope that is good enough. -- Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5 *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE SSLEAY GPK4000
On Sat, Jun 26, 1999 at 12:29:36AM +0200, Erwann ABALEA wrote: On Sat, 26 Jun 1999, Jason wrote: Hi I am currently working on the SSLEAY crypto libraries and the Gemplus GPK4000 cards. When I sign a message using SSLEAY md5() and rsa_public_encrypt(), I get a signature string. However when I perform the signature using GPK4000 I get a different string. Both return 64 bytes. First of all, please don't use SSLeay anymore, as the project has been renamed to OpenSSL (www.openssl.org). Eric Young is now working for RSA, and SSLeay is no longer maintained. Then... Are you sure the padding method used by the GPK4k is the same as the one used by SSLeay? The keys which are loaded into the card were created by SSLEAY rsageneratekey(). These keys are then stored into file in ASCII format (0-F).These keys are then converted into a binary string and loaded into the card. Are you sure the key components are correct for the GPK4k (this card has some constraints for the key parameters). The format required to private load keys into the GPK is pretty bizarre. This is probably where the problem is. BTW. The plain text message before digest is 6 bytes (012345). I assume padding is done automatically by the SSLeay MD5 functions. RSAprivatencrypt uses PCKS-1 padding. MD5() should return a 16 byte value. This is then padded with PKCS#1 padding (block type, pad bytes, ASN.1 BER, hash) by the GPK before RSA encryption. The GPK4000 will do PKCS#1 padding for you. It will do the correct padding for MD5, SHA1, and SSL (MD5SHA1) hashing.However if I remember right, you must send the correct number of bytes. That's how it tells which hash you're feeding it. Also, are you sure that you're using the same PKCS#1? The GPK uses v1.5 but there is a new v2.0 standard out since last summer, which is very different and is based on the OAEP padding scheme to prevent adaptive ciphertext attack. I haven't looked at newer SSLeay but there is a chance that they put that in. -- Eric Murray N*Able Technologieswww.nabletech.com (email: ericm at the sites lne.com or nabletech.com) PGP keyid:E03F65E5 *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
