Importing a symmetric private key into NSS?
Hello, I've been trying to import an AES 256 encrypted RSA Private Key imported into NSS, to function as a PKCS 11 AES Secret Key Object (aka object class CKO_SECRET_KEY, key type CKK_AES), but have been unsuccessful. I attempted this using the symkeyutil tool, but it fails with the following error $ nss-symkeyutil -K -n Test -t aes -s 256 -d . Enter Password or Pin for NSS Certificate DB: nss-symkeyutil: Token Key Gen Failed nss-symkeyutil: The key does not support the requested operation. I get the same error if I try and import a key that I generated via openssl. Is importing AES keys (as a PKCS11 Secret Key) into NSS supported? And if so, how do I do it? The version of NSS : $ port list installed | grep nss nss@3.12.7 net/nss Thanks! Deepak. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 2010/10/28 03:12 PDT, Jean-Marc Desperrier wrote: Nelson B Bolyard wrote: [...] It because none of them: J-PAKE, SPEKE, SRP, or for that matter, good old CRAM-MD5 address the NUMBER ONE problem with passwords. PHISHING. They are a very significant progress with regard to that actually. What do JPAKE, SPEKE and SRP claim to give you that CRAM-MD5 does not? ZERO-KNOWLEDGE That's resistance to something other than phishing. That's dealing with an untrustworthy peer, with whom you WANT to trust, to the point that you do give that party an authenticator of some sort. That's NOT the big problem. The server can not attack by brute-force the content of the exchange to deduce what you password is. Right, so the attacker just asks you for it, very convincingly. Now, that's not it : What they truly bring is that if you are misled into making an handshake with a phishing site, you don't give to that site any information about what your password might be. Sorry, untrue. The attacker puts up a password dialog. You type your password into it. You give away your password. Maybe YOU (JMD) don't, but then, you (JMD) aren't the typical phishing victim. You have a good idea what to look out for. The phishing victim does not, and so enters his password anywhere that asks, because he cannot (or will not) distinguish between the places where he should and those where he shouldn't. If you are tricked into making the handshake with the wrong site, there's no bad consequence. Right. That attack is not to get you to HANDSHAKE with the wrong site. It's to get you to connect to the wrong site that ASKS YOU TO ENTER YOUR PASSWORD. So the risk is to be tricked into entering your password inside a field that doesn't do a handshake, but instead just sends copy of it to the pirate. Right. Therefore password exchange solution that relies on you entering the password inside a standard web page are still strongly vulnerable to the phishing problem, and there's no progress over older password schemes. Right. But if the password is entered inside an element that is unambiguously the GUI of your browser, web site can not do a phishing attack against it any more, and the solution is actually quite good. ... ASSUMING that the user is bright enough to understand the difference between chrome and non-chrome, and which one is trustworthy ... but years of experience have shown us that most users are not. For years, and to this very day, web sites put lock icons in the pages to try to convince the users that the page is secure. My own bank does it! MOST users still have no clue about trust of chrome vs trust of web page content. Not a clue. I had a bank account executive sit in front of a browser once, and instruct me in how to use the browser to do on-line banking. I sat through his presentation (despite having been a user of online banking for over a decade by then) to see how well HE understood it. He informed me that he was specially trained by his bank to train customers in how to lower their risk of being swindled. The FIRST THING he told me was to look for the lock icon in the web page content to be sure I was looking at a secure page, before typing in my bank password. I asked him what was the difference between that lock icon and the one down in the corner of the window, against the background that matched the window border (he was using MSIE). He had never noticed that lower icon before, and had no idea what it meant. So much for his special training. No, passwords simply have NO PLACE in protecting the average user from phishing. And it doesn't matter whether the password is used to derive a session encryption key, or just as an authentication token. The user is just as vulnerable either way. A password user's best protection against attack is simply appearing to be a low-value target. There are so many of them waiting to be attacked that the trick is to appear to be less worth attacking than one of the millions of others. Therefore the actual gap in security between the two is : - A : An attaquer that find a way to create a windows that tricks users to believe it's the genuine Firefox GUI for the password, without having to use chrome privilege. No need to convince the user that it's genuine Firefox GUI because the user has no idea what the significance of that is. Any ordinary web page with a password field in the page content will suffice. - B : An attaquer that uses the usual weaknesses of passwords to get access without phishing the user. Those usual weaknesses being that passwords are frequently very weak, but the worst I believe is that users frequently reuse them. So the attacker could obtain the value of the password of the user at another site, and use it to guess accurately what he's using at the protected site. Yup. That's another reason why you don't want the
Re: Invalide certificate encoding crashing certutil [Re: Thunderbird: Could not verify this certificate for unknown reasons]
On 2010/10/28 02:14 PDT, Jean-Marc Desperrier wrote: Nelson B Bolyard wrote: Please don't file a bug without a stack trace showing the crash is in NSS. [...] If the back trace shows the crash is not in NSS, but in some other library, please direct the bug report accordingly. The report is that the crashs is inside NSS's certutil, Nelson. Perhaps I have confused this Matej with another. I understood that Matej is developing his own PKCS#11 module, and his report is that NSS's certutil crashes when run with his non-NSS PKCS#11 module. The crash may well be in that module. Matej, If I'm confused, feel free to set me straight. As Thunderbird with the same data doesn't crash, it doesn't seem to actually be in the library, but even just in a NSS tool, a crash is serious. Show me that the crash occurred in NSS code, and not in the code of some PKCS#11 module, and I'll be more convinced. A bug report that says nothing more than I ran this program with this other PKCS#11 module and it crashed won't yield any desirable results, unless someone happens to say Oh I saw that too and fixed it by -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Invalide certificate encoding crashing certutil [Re: Thunderbird: Could not verify this certificate for unknown reasons]
On 29. 10. 2010 14:11, Nelson B Bolyard wrote: On 2010/10/28 02:14 PDT, Jean-Marc Desperrier wrote: Nelson B Bolyard wrote: Please don't file a bug without a stack trace showing the crash is in NSS. [...] If the back trace shows the crash is not in NSS, but in some other library, please direct the bug report accordingly. The report is that the crashs is inside NSS's certutil, Nelson. Perhaps I have confused this Matej with another. I understood that Matej is developing his own PKCS#11 module, and his report is that NSS's certutil crashes when run with his non-NSS PKCS#11 module. The crash may well be in that module. Matej, If I'm confused, feel free to set me straight. You are right, Nelson. M. Kurpel -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 10/29/2010 03:44 AM, Nelson B Bolyard wrote: On 2010/10/28 03:12 PDT, Jean-Marc Desperrier wrote: Nelson B Bolyard wrote: [...] It because none of them: J-PAKE, SPEKE, SRP, or for that matter, good old CRAM-MD5 address the NUMBER ONE problem with passwords. PHISHING. They are a very significant progress with regard to that actually. What do JPAKE, SPEKE and SRP claim to give you that CRAM-MD5 does not? ZERO-KNOWLEDGE That's resistance to something other than phishing. That's dealing with an untrustworthy peer, with whom you WANT to trust, to the point that you do give that party an authenticator of some sort. If I understand it correctly, one thing it does do is convert an offline password cracking attack into an active real-time MitM. The attacker is required to use the session right then, he can not harvest the login credentials for later use. Now, the extent to which this represents a real improvement in the effective security of the average user is a very open question. I think that in practice, fewer attackers have demonstrated an online attack capability (e.g. Zeus) than have using simple password harvesting. But if somehow they ran out of usable password credentials to steal, they'd probably become more sophisticated. That's NOT the big problem. [...] Right, so the attacker just asks you for it, very convincingly. The attacker puts up a password dialog. You type your password into it. You give away your password. ... ASSUMING that the user is bright enough to understand the difference between chrome and non-chrome, and which one is trustworthy ... but years of experience have shown us that most users are not. It's impossible to discuss security unless we're able to expect some minimal degree of competence on the part of the user. This applies to telephone and mail scams just as much as data security. Instead of the chrome/nonchrome lock icon distinction, we could equally say that typical users are willing to download and install executables, at which all bets are off. I've even heard of a (non-US) bank that required users to do exactly that in order to access its site! Whether or not Firefox can make an effective UI for this kind of security is an altogether different question. My guess is that if Mozilla doesn't do the best possible job of it with Firefox, extension developers and/or Google Chrome will. For years, and to this very day, web sites put lock icons in the pages to try to convince the users that the page is secure. They may be in part reacting to users' expectations of lock icons. Or graphic designers simply like to decorate the page with little logos. My own bank does it! MOST users still have no clue about trust of chrome vs trust of web page content. Not a clue. Just a personal anecdote, I find the color changes in the address bar to be a good visual indicator. The red background really stands out when you're used to seeing blue there. I had a bank account executive sit in front of a browser once, and instruct me in how to use the browser to do on-line banking. I sat through his presentation (despite having been a user of online banking for over a decade by then) to see how well HE understood it. He informed me that he was specially trained by his bank to train customers in how to lower their risk of being swindled. The FIRST THING he told me was to look for the lock icon in the web page content to be sure I was looking at a secure page, before typing in my bank password. I asked him what was the difference between that lock icon and the one down in the corner of the window, against the background that matched the window border (he was using MSIE). He had never noticed that lower icon before, and had no idea what it meant. So much for his special training. Classic! No, passwords simply have NO PLACE in protecting the average user from phishing. And it doesn't matter whether the password is used to derive a session encryption key, or just as an authentication token. The user is just as vulnerable either way. Even myself, whom I consider pretty paranoid about these things, occasionally enter the right password (for one system) into the wrong password field. A password user's best protection against attack is simply appearing to be a low-value target. There are so many of them waiting to be attacked that the trick is to appear to be less worth attacking than one of the millions of others. Which only works if you don't have enough to lose to make you worth of a targeted attack. Hardware protected private keys have a much more significant added value than software ones when compared to those schemes. Unfortunately they are still very little used. Except in China, surprisingly (Banks there have distributed millions of PKI hardware token to identify on their web sites) Yeah, the Russian banks all do this, too. Why can't the bankers in the free world have as much of a clue about network security as those
pk11util
Hello, I would like to get my hands on pk11util to check my PKCS#11 module for conformance to said standard (my search on the net yielded that pk11util is suitable for this purpose). However, the precompiled NSS for windows does not contain this utility. I have tried to compile it myself (yes, again and again) but after a few hours of trial-and-error I simply gave up. Could someone please point me to a place where I could download pk11util.exe ready to use? My google search came up with nothing useful. Or suggest some other utility to perform checks for PKCS#11 standard conformance (something like W3C's markup validator, heh). Thanks, M. Kurpel -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Importing a symmetric private key into NSS?
On 10/28/2010 11:39 PM, Deepak wrote: Hello, I've been trying to import an AES 256 encrypted RSA Private Key imported into NSS, to function as a PKCS 11 AES Secret Key Object (aka object class CKO_SECRET_KEY, key type CKK_AES), but have been unsuccessful. Confusion. Do you mean a pkcs #12 AES 256 bit encrypted key? That should work with pk12util. When most people say AES 256 encrypted RSA PrivateKey they mean a private key wrapped with an AES 256 PBE generated key. In that case there is no need to import another AES key. I'm confused because the whole rest of this post is asking about importing AES symmetric keys. Do you have an RSA Private Key wrapped with some fixed symmetric key? I attempted this using the symkeyutil tool, but it fails with the following error $ nss-symkeyutil -K -n Test -t aes -s 256 -d . Enter Password or Pin for NSS Certificate DB: nss-symkeyutil: Token Key Gen Failed nss-symkeyutil: The key does not support the requested operation. I get the same error if I try and import a key that I generated via openssl. I've never heard of the nss-symkeyutil. There is a sample app called symkeyutil, but last I checked it was incomplete, though there may have been some work to get it working. From a tools perspective I don't know if there is a way to move an AES symetric key around.. But your question was an RSA private key. Is importing AES keys (as a PKCS11 Secret Key) into NSS supported? And if so, how do I do it? It's not clear if you are asking 'Programmatically' or with utilities. Programmatically, The only issue importing any key is how you do it. If the token is in FIPS mode, you have to key exchange it. If it's not, PK11_ImportSymKey() should do the trick. (Caveat, not guaranteed to work in all tokens, serious security systems should be able to avoid it;). bob The version of NSS : $ port list installed | grep nss nss@3.12.7 net/nss Thanks! Deepak. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Importing a symmetric private key into NSS?
On 10/29/2010 03:36 PM, Deepak Kumar wrote: Rob, thanks for the response. This is still a new domain for me, so undoubtedly I'm getting some terminology mixed up. Backing up, and to try and be clear, what I'm trying to do is import a symmetric AES encryption key into NSS. OK I've never heard of the nss-symkeyutil. There is a sample app called symkeyutil, but last I checked it was incomplete, though there may have been some work to get it working. From a tools perspective I don't know if there is a way to move an AES symetric key around.. But your question was an RSA private key. Good to know, thanks. MacPorts packages the nss tools (including sample apps, it appears) with the nss- prefix. So the modutil binary is invoked as nss-modutil, for example. I'm able to get des3 keys imported using the symkeyutil tool/app, but it fails on aes ones with the nss-symkeyutil: Token Key Gen Failed nss-symkeyutil: The key does not support the requested operation. error. If symkeyutil works with des3 but not aes, and it's a reasonably recent version, then you should write a bug against symkeyutil (be sure to use the normal NSS name). Do you know what version of NSS you are using? bob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
