Re: Default Password callback

[Robert Relyea]

On 10/1/20 5:37 AM, Daniel Gustafsson wrote:

I'm implementing support for NSS into a codebase which already has OpenSSL
support, and when looking at the passphrase callbacks I ran into a question.

Is my understanding correctl that there is no default password callback like
how OpenSSL has a fallback reading from a TTY?  SECU_GetModulePassword and the
supporting functions are clearly private and not exposed, but since the docs
don't spell it out I wanted to doublecheck to make sure I hadn't missed
anything.


That's correct. NSS is often run with windowed systems, so only the 
application knows how to get to the user to prompt for a password.


SECU_GetModulePassword is part of the command line utilities library, 
which you could grab and use in your application.



bob



cheers ./daniel



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: No Post Quantum this week.

[Robert Relyea]

On 9/14/20 10:19 AM, Robert Relyea wrote:

Bob has a dental appointment and will be out. See you in 2 weeks.

bob


Went to the wrong list. You can ignore this.

bob

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

No Post Quantum this week.

[Robert Relyea]

Bob has a dental appointment and will be out. See you in 2 weeks.

bob

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Regarding SQLite in NSS 3.44.4

[Robert Relyea]

On 8/7/20 1:27 AM, Rahul S wrote:

Hi Team,

Hope all are doing good!

I would like to get some clarification about the SQLite version in NSS 
3.44.4. From release notes of NSS 3.46, i see that the "Bug 1550636 
- Upgrade SQLite 
in NSS to a 2019 version"


has been fixed .Is the upgraded  SQLite version also available in NSS 
3.44.4?


It's unlikely. On the other hand, not all instances of NSS come with the 
imbedded SQLite library. Most NSS instances use an external library 
(either included in the operating system or included with the 
application using NSS).


On linux, for instance, NSS uses the system SQLite, which is often newer 
than the version shipped with NSS. In Mozilla products, Mozilla includes 
their own copy of sqlite which NSS uses.


In these cases, you won't find a copy of sqlite in NSS, but instead nss 
uses the system copy.



bob




Best Regards,

Rahul.S



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.53 release

[Robert Relyea]

On 6/10/20 10:48 PM, Martin Thomson wrote:

Is there an automated check we can run that will help us remember to
do this properly in future?  I really don't like having to remember
this sort of thing.



There isn't, which is why it happened, I think we should have one 
though, where would be the best place to put it? nss/automation?


bob



On Thu, Jun 11, 2020 at 3:52 AM Robert Relyea  wrote:

On 6/1/20 5:18 PM, JC Jones wrote:

The NSS team released Network Security Services (NSS) 3.53 on 29 May 2020. NSS 
3.53 will be a long-term support release, supporting Firefox 78 ESR.


Looks like we updated certdata.txt without updating the version number
in nssckbi.h. This caused some problems because I pulled the 3.52
certdata.txt, but with 3.53 coming out I verified that version number
didn't change and didn't pick up the 3.53 change.

We need to make sure we bump the version number when we make changes.
Just a reminder for the future...

Fortunately our QA tests found this, and I had already pushed our
version number because I removed a bunch of expired certs (that weren't
explicitly marked as untrusted). I'll create a bug to remove those from
the upstream certdata.txt and that will put the versions in sync again.


bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.53 release

[Robert Relyea]

On 6/1/20 5:18 PM, JC Jones wrote:

The NSS team released Network Security Services (NSS) 3.53 on 29 May 2020. NSS 
3.53 will be a long-term support release, supporting Firefox 78 ESR.



Looks like we updated certdata.txt without updating the version number 
in nssckbi.h. This caused some problems because I pulled the 3.52 
certdata.txt, but with 3.53 coming out I verified that version number 
didn't change and didn't pick up the 3.53 change.


We need to make sure we bump the version number when we make changes. 
Just a reminder for the future...


Fortunately our QA tests found this, and I had already pushed our 
version number because I removed a bunch of expired certs (that weren't 
explicitly marked as untrusted). I'll create a bug to remove those from 
the upstream certdata.txt and that will put the versions in sync again.



bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Crypto team minutes 202-05-12

[Robert Relyea]

Please ignore this, it went to the wrong list.


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Crypto team minutes 202-05-12

[Robert Relyea]

Date: 2020-05-12
Chair: Ivan
Minutes: Bob
Participants: Alex, Standa, Jakub, Bob, Daiki, Toshi, Simo, Tomas, 
Sahana, Hubert, Ondrej, Ivan, Lucie

Excused: Nikos

Chair and minutes keeper update etherpad, after the meeting the minutes 
keeper sends minutes and prepares etherpad for next week - 
https://wiki.brq.redhat.com/SecurityTechnologies/CryptoTeam#Meetingsandminutes


* Meeting administrivia/announcements (5 mins)

[announce this meeting chair/notes keeper]
[decide  next meeting chair/notes keeper Bob -> Daiki -> Hubert ->  
Sahana -> Jakub -> Simo ->  Tomas -> Alexander -> Lucka  -> Standa -> 
Toshi -> Ondrej -> Ivan]


Next meeting chair: Bob
Next meeting minutes: Daiki


* Check of issue queries (10 min)

Report of NEW untriaged items the last two weeks and items with needinfo:
https://url.corp.redhat.com/crypto-team-chairman-reportv6 (6)

RHEL8.3:
 * non-acked: https://url.corp.redhat.com/crypto-rhel83-nonacked-v1 (13)
 * untriaged: https://url.corp.redhat.com/crypto-rhel83-untriaged-v1 (2)
 * unscoped: https://url.corp.redhat.com/crypto-rhel83-unscoped-v2 (8)
 * ON_QA bugs: https://url.corp.redhat.com/crypto-rhel83-onqa-v1 (6)

RHEL7.9:
 * untriaged bugs 
https://url.corp.redhat.com/crypto-rhel79-untriaged-v1 [please triage or 
close; do not postpone (except for ca-certificates and nss*)] (3)



* PTOs (0 min)

Standa: May 15th

* Status report on previous action points (5 min) [note: no discussion 
only status]


AI All: Skim through the Maturity Model document and give feedback.
Done

AI Hubert, Anderson and Jakub: discuss Quantum-resistant SSH Key 
Exchange in a seperate meeting.

done: discussed on irc.

Chess tournament:
Interested: Standa, Hubert, Ivan, Sahana (prefer classical), Simo (I am 
ok with blitz 10min or no time limit), Jakub

done :)

* Check Ready for Acceptance (10 min)

Jira: 
https://projects.engineering.redhat.com/secure/RapidBoard.jspa?rapidView=3019



* Update on running theses and internship (1 min)

Hubert: (timing attacks with tlsfuzzer): new PR I need to review
Hubert: (cipherscan TLS 1.3 support): no update

Interns:
Frantisek: new PR I need to review
Norbert: presentation and demo at monthly meeting



MUNI + Red Hat collaboration on post-quantum crypto + side-channel 
resistance:

https://docs.google.com/document/d/1qQlkawjxXkaz05aseCDXAgGEdZtkcY7MdtxJXsaRQo8/edit#heading=h.5m4tl0gyigmi
no update


* Update on running projects (3 min)

Daiki: QUIC and HTTP/3
https://projects.engineering.redhat.com/browse/CRYPTO-398
no progress


* Deadlines

2020-01-21: RHEL-8.2 bugs require exception or blocker
2020-01-27: RHEL-8.1.0.z Batch 2 -  Errata in REL_PREP
2020-02-11: RPL for 7.9 deadline
2020-02-25: Q4 review SST meeting
2020-02-25: Fedora 32 Beta Freeze
2020-02-29: Q4 Ends
2020-03-26: RHEL-7.9 bugs require exception or blocker
2020-03-30: RHEL 8.1.0.3 all Errata in REL_PREP [openssl]
2020-03-30: RHEL 8.2 all Errata in REL_PREP
2020-03-31: RHEL 8.3 RPL SST deadline
2020-04-24: Mid quarter Review and planning completion
> we are here <-
2020-06-01: Firefox 78 Beta freeze
2020-06-02: OpenSSL 3.0 Beta release (feature freeze)
2020-06-30: Firefox ESR 78.0 release
2020-07-13: RHEL-7.9 all Errata on REL_PREP


* Discussion (25 mins)

Alex: let's vote on results-yesterday project proposal 
(https://projects.engineering.redhat.com/browse/CRYPTO-1198)

Alex wants to know what the process to move forward.
Simo: we just need to vote
Vote: Approved, no objections.
Simo: Be sure to reply to any requests to this Jira card in a timely 
manner. Management may ask time critical questions here.
Standa: You need to explicitly watch a bug, even if you own the card to 
get notifications.


Tomas: In 8.2 custom crypto-policies bring python into the minimal 
rhel-8 container image - should we make the update-crypto-policies a 
subpackage pulled in via "Recommends"?

Tomas: in fedora we use this method.
Simo: why would we worry about this in RHEL.
Tomas: customers may ignore the Recommends and not get 
update-crypto-policies. There may be a work around would be to put the 
tool in, but put a runtime warning.
Simo: Better to not have the tool. Just do the Recommends and customers 
that need the tool can figure out if they bypass recommends.

AI Tomas: Put the crypto-policies bug in the 8.3 errata

Tomas: Heads-up - Thunderbird (which we ship in RHEL) will from version 
78 require Botan crypto library :(

    Simo: why? what is it used for?
    Kai Engert said on nss-dev ML: "For OpenPGP we're using the RNP and 
Botan libraries. [...] We'll NOT bundle GnuPG because of its GPL license."

    Bob: You can build it without it but you wont get PGP.
    Simo: ideally we want this support as a plugin in EPEL.
    Simo: make sure RHEL thunderbird knows about.
    AI: Tomas make sure there is a downstream RHEL bug for Botan issue 
in Thunderbird.


Alex: definition of done for 'fix tests on Fedora': passes in Beaker on 
x86? has a reviewed TCMS run? passes in

Re: [key4.db] IV size for aes256-CBC

[Robert Relyea]

On 04/22/2020 01:21 AM, laurent.cl...@gmail.com wrote:

On Monday, March 30, 2020 at 6:28:55 PM UTC+2, Robert Relyea wrote:

On 03/27/2020 12:21 PM, Louis Abraham wrote:

Hi Matthew,

Awesome, thanks and sorry for contacting the wrong list!

Since then, I found the answer to the 14 bytes question:
https://hg.mozilla.org/projects/nss/rev/fc636973ad06392d11597620b602779b4af312f6#l6.49
Basically the DER encoding is used instead for compatibility with a
bugged implementation.

I tried prepending |b'\x04\x0e'| to DER-encode the IV. However, the
value I get makes no sense (and even has an incorrect padding
according to pkcs7 <https://tools.ietf.org/html/rfc2315>).


Best,

Louis


The IV length is still 16 bytes, but only 14 are randomly generated.
It's because the decoding code had a bug in it that requires the IV to
look like der encoded data, so the header needed to be added, but the
whole IV was used (including the 2 byte header) when encrypting/decrypting.

The goal of the AES-256 bit code was  to encode AES-256 while allowing
older versions of NSS to still decrypt the new keys, since versions of
NSS may share their databases with other NSS applications running on
other machines.

bob

Le ven. 27 mars 2020 à 19:57, Matthew N. mailto:ma...@mozilla.com>> a écrit :

 Hi Louis,

 The dev-tech-crypto mailing list I'm redirecting this to should be
 able to get you an answer.

 Thanks,
 MattN


 On Fri, Mar 27, 2020 at 8:51 AM Louis Abraham
 mailto:louis.abra...@yahoo.fr>> wrote:

 Hi,

 I'm the main developer of https://github.com/louisabraham/ffpass
 We are currently trying to accommodate the (not so) recent
 cryptographic changes in key4.db.

 If I understand correctly, key4.db contains a table metadata.
 The value item2 defines a cryptographic algorithm in the DER
 format.

 In the latest version of Firefox, this algorithm is PBES2,
 using aes256-CBC as the encryption algorithm.

 I'm facing a little problem when trying to execute aes256-CBC
 because the IV size is only 14 bytes (56 bits) instead of the
 64 bits defined in the spec.

 Could you please help me to understand?

 Best,
 Louis


Hi Robert,

For PBKDF2, why the iteration value is only 1  by default ?
the recommandation is 1: 
https://cryptosense.com/blog/parameter-choice-for-pbkdf2/

is it the value 1 in this ASN1 data ?

SEQUENCE {
  OBJECTIDENTIFIER 1.2.840.113549.1.5.12 pkcs5 PBKDF2
  SEQUENCE {
OCTETSTRING 
b'f92dde91809b8b00c6607b73f3d0321c80f930aa13f13da5293aede76ee92048'
INTEGER b'01' <- iterations ?
INTEGER b'20'
SEQUENCE {
  OBJECTIDENTIFIER 1.2.840.113549.2.9 hmacWithSHA256
}
  }
}

Laurent,
author of https://github.com/lclevy/firepwd


There's a separate patch the increases is supposed to increase the 
iteration count. I believe it landed after the AES changes.


bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [key4.db] IV size for aes256-CBC

[Robert Relyea]

On 03/27/2020 12:21 PM, Louis Abraham wrote:

Hi Matthew,

Awesome, thanks and sorry for contacting the wrong list!

Since then, I found the answer to the 14 bytes question: 
https://hg.mozilla.org/projects/nss/rev/fc636973ad06392d11597620b602779b4af312f6#l6.49
Basically the DER encoding is used instead for compatibility with a 
bugged implementation.


I tried prepending |b'\x04\x0e'| to DER-encode the IV. However, the 
value I get makes no sense (and even has an incorrect padding 
according to pkcs7 ).



Best,

Louis

The IV length is still 16 bytes, but only 14 are randomly generated. 
It's because the decoding code had a bug in it that requires the IV to 
look like der encoded data, so the header needed to be added, but the 
whole IV was used (including the 2 byte header) when encrypting/decrypting.


The goal of the AES-256 bit code was  to encode AES-256 while allowing 
older versions of NSS to still decrypt the new keys, since versions of 
NSS may share their databases with other NSS applications running on 
other machines.


bob


Le ven. 27 mars 2020 à 19:57, Matthew N. > a écrit :


Hi Louis,

The dev-tech-crypto mailing list I'm redirecting this to should be
able to get you an answer.

Thanks,
MattN


On Fri, Mar 27, 2020 at 8:51 AM Louis Abraham
mailto:louis.abra...@yahoo.fr>> wrote:

Hi,

I'm the main developer of https://github.com/louisabraham/ffpass
We are currently trying to accommodate the (not so) recent
cryptographic changes in key4.db.

If I understand correctly, key4.db contains a table metadata.
The value item2 defines a cryptographic algorithm in the DER
format.

In the latest version of Firefox, this algorithm is PBES2,
using aes256-CBC as the encryption algorithm.

I'm facing a little problem when trying to execute aes256-CBC
because the IV size is only 14 bytes (56 bits) instead of the
64 bits defined in the spec.

Could you please help me to understand?

Best,
Louis



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

NSS ESR release date.

[Robert Relyea]

Red Hat Planning would like to know the estimate for when the NSS 
targetted for ESR will be released. We are working on the theory it will 
be end of May (balancing time for PKCS #11 3.0 changes versus when ESR 
needs a new NSS). Planning wants me to confirm that with mozilla, 
particularly JC.


Thanks,

bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.44 Release

[Robert Relyea]

On 05/17/2019 08:54 AM, JC Jones wrote:

On Thursday, May 16, 2019 at 9:28:39 AM UTC-7, Paul Wouters wrote:


Wait, what?

They need work to make them simpler and better support cross compiling
for sure, but getting rid of them would really hamper our use of NSS
on different platforms. How would you support that without Makefiles?

Paul

'build.sh' uses ninja-build and gyp rather than the Makefiles. I know those 
tools don't have total platform coverage yet, but it's getting close.

What platforms are you using that aren't covered? It's almost certainly easier 
to improve those tools than it is to revamp the Makefiles.


Except Makefiles still work and are how RH builds NSS. I'm sympathetic 
to how gyp files makes mozilla's life easier, but we get zero benefit 
from them, so we need a nice long discussion before we 'start to phase 
out' makefiles.


Please don't make these kinds of decisions and announcements without 
some concurrence from us.



bob


J.C.



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Is there some problem with treeherder?

[Robert Relyea]

I've been trying to get an nss-try builds with nss-tools for a couple of 
days now, but it looks like both nss-try and nss are not properly 
running any tests. Is there an outage, or do we need someone to kick the 
try servers?



bob

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Linker error from tstclnt

[Robert Relyea]

On 11/22/2017 07:24 AM, Kai Engert wrote:

On 10.11.2017 10:16, muni.pra...@gmail.com wrote:

USE_STATIC_RTL=1

I haven't seen this symbol before, maybe it's no longer supported.

Does it work if you don't define it?


The symbol means build the test binaries with static libraries. That 
hasn't been officially supported by NSS for quite some time (though it 
may accidentally work on some platforms). Only certain low level test 
apps whould use the static run time, and they explicitly set the value 
in their makefiles.


bob


Kai



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Are NSS bug fix releases still FIPS 140-2 certified?

[Robert Relyea]

On 04/10/2017 02:58 PM, Ernie Kovak wrote:

Kyle Hamilton is right. The authoritative document is the NSS module's security 
policy, which is linked from their validation certificate (see above). That 
policy specifies how the module can be used in order to be FIPS 140-2 compliant.

According to the NIST FIPS 140-2 Implementation Guide 
(http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf) there 
are only a couple things you can do to a module once it's been validated:

The vendor can fix non-security related bugs and update their validation (as 
opposed to a full re-validation of the module), and

Users can build the module from sources for the purpose of porting to new 
platforms IFF the security policy includes specific build procedures. But the 
NSS security policy contains no such build procedures. Look at the OpenSSL 
policy for an example of one that does.

So this is a little in accurate in that:
1) Only the validating vendor can do a 'vendor affirm' on a new plaform. 
Each openSSL vendors that want FIPS validations do their own validation.
2) That vendor can do a 'vendor affirm' without any documented build 
procedures.


So the conclusion below is correct with respect to the Red Hat 
validation, but it's true because Red Hat has not vendor affirmed any 
other platforms. It is not the case that openSSL is any more validated.

That means NSS does not provide FIPS compliance on any platform other than the 
one they tested on. So, not on Windows. Not anywhere other than Red Hat 
Enterprise Linux on a few platforms.







--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to get a list of SubjectAltNames of a cert in NSS

[Robert Relyea]

On 03/03/2017 02:48 PM, Robert Relyea wrote:

On 03/03/2017 09:42 AM, Paul Wouters wrote:

On Fri, 3 Mar 2017, Robert Relyea wrote:


 [offlist]


redirected back to the list, since the item I was concerned about is not
a concern.


 Thanks for the info. I looked at it and have two questions and one
 concern (which is why this is offlist)
I'm not sure what list this was from. I don't remember seeing the 
thread.


dev-tech-crypto@lists.mozilla.org


 - Why not export this NSS function for everyone?


Which function?


Sorry, I was referring to:

cert_VerifySubjectAltName(const CERTCertificate *cert, const char 
*name);


Certainly as named, we would export it, but we could wrap the function 
as CERT_VerifySubjectAltName()
and export that function. 


Arg... typing to fast drops negations. this should read

"Certainly as names we would NOT export it, but we could wrap the 
function as CERT_VerifySubjectAltName() and export that function()."


Lower case function names is an indicator the the function is local, at 
least to the NSS directory, if not to the .c file itself. Anything 
exported even within the NSS shared library (yet alone to the 
application) sould have an all cap prefix.


bob

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to get a list of SubjectAltNames of a cert in NSS

[Robert Relyea]

On 03/03/2017 09:42 AM, Paul Wouters wrote:

On Fri, 3 Mar 2017, Robert Relyea wrote:


 [offlist]


redirected back to the list, since the item I was concerned about is not
a concern.


 Thanks for the info. I looked at it and have two questions and one
 concern (which is why this is offlist)
I'm not sure what list this was from. I don't remember seeing the 
thread.


dev-tech-crypto@lists.mozilla.org


 - Why not export this NSS function for everyone?


Which function?


Sorry, I was referring to:

cert_VerifySubjectAltName(const CERTCertificate *cert, const char 
*name);


Certainly as named, we would export it, but we could wrap the function 
as CERT_VerifySubjectAltName()

and export that function.




Basically in IKE you can set an ID different from a DN. So if someone
sets ID_FQDN (eg vpn.example.com) then we want to lookup and ensure that
the certificate is really matching that ID. IKE also allows specifying
email addresses and IP's. So we need to look for:

- email= in the DN
- subjectAltName of type DNSname
- subjectAltName of type IP
- subjectAltName of type email address.

It looks that CERT_GetFirstEmailAddress() and CERT_GetNextEmailAddress()
gets me the email= from the DN and all email address in the first
subjectAltName section, but not in subsequent subjectAltName sections.


Yes, NSS only looks at the first subjectAltName section. That section 
can and should hold all the alt names (That's certainly the case with 
SSL certificates).


I think you may be confused with the openSSL API. When openSSL says:

Please make sure the following details are correct before proceeding any 
further.

CommonName: server1.example.com
subjectAltName: DNS:server1.example.com
subjectAltName: DNS:mail.example.com
subjectAltName: DNS:www.example.com
subjectAltName: DNS:www.sub.example.com
subjectAltName: DNS:mx.example.com
subjectAltName: DNS:support.example.com
No additional information will be included on certificates because it can not 
be automatically checked by the system.

It will create a single subjectAltName with all those names in it:

X509v3 Subject Alternative Name:
DNS:server1.example.com, othername:, DNS:mail.example.com, 
othername:, DNS:www.example.com, othername:, DNS
:www.sub.example.com, othername:, DNS:mx.example.com, othername:, DNS:support.example.com, othername:

Are you sure the certificate you have actually has multiple 
subjectAltName sections?




The same is true for cert_VerifySubjectAltName() which seems to only
look at the first subjectAltName section as well.

The certificates I use for testing use this openssl/python code:

-   add_ext(cert, 'subjectAltName', False, dnsname)
+   if cnstr == "east.testing.libreswan.org":
+   dnsname = "%s,%s"%(dnsname , "DNS:east.alias")
+   add_ext(cert, 'subjectAltName', False, "IP: 
192.1.2.23")

+   add_ext(cert, 'subjectAltName', False, dnsname)
+   add_ext(cert, 'subjectAltName', False, "email: 
user1@%s"%cnstr)


So there are 3 subjectAltName sections.


Hmm Are you sure these aren't being colapsed into a single 
subjectAltName section with multiple subjectAltNames in it?


In general NSS tends to be stingy by default on the functions it 
exports,


I completely understand that :)

I believe Kai has already exported several functions upstream for you 
that will go into RHEL 7.


Yes, and we've already updated libreswan to make use of this in upstream
and fedora rawhide! Thanks!


 The code I see in NSS seems to assume there is only one SAN section? I
 checked and it does not create one big list of all the SAN extensions,
 because I don't see my IP address SAN in the above example.


It doesn't. For most of NSS we usually are looking for a specific SAN 
(like a particular DNS name, or an email address.), so it loops 
through them all.


I'm surprised the SAN processing isn't exported since applications 
that override the SSL name check would need it.


You do export CERT_VerifyCertName() which uses this function. So maybe I
was trying to use the wrong function. But it seems this function also
does not process multiple subjectAltName sections.


CERT_VerifyCertName() verifies against either the SAN or the CN (SSL 
processing). it supports multiple subjectAltNames, but they all are 
expected to be in the same section.


bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Should PK11_Derive() save the failure status?

[Robert Relyea]

On 02/22/2017 10:44 AM, Andrew Cagney wrote:

Hi,

I've got a PK11_Derive() call failing (presumably something silly on
my part), but frustratingly, PORT_GetError() just returns 0.

It seems that all variants of PK11_Derive() don't call:

 PORT_SetError(PK11_MapError(crv));

with the error status from ->C_DeriveKey().  Should they?


Yes, please write a bug on this. The mapping should happen directly 
after the C_DeriveKey() call.


bob

   Or is there
some other way (short of debugging) to get at least a hint has to my
error.

Andrew



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: xmlsec / ECDSA problem

[Robert Relyea]

On 02/14/2017 03:07 AM, Miklos Vajna wrote:

Hi,

xmlsec from  is a library to verify XML
signatures (and more). It has a number of backends, one of them being
NSS. Currently only the openssl backend of xmlsec supports ECDSA, and
I'm trying to add support for ECDSA in its NSS backend. My first goal
would be verifying a signature I know is valid (since openssl accepts
it).

Here is my work-in-progress code:

https://github.com/vmiklos/xmlsec/commit/fd56f6d42819cbd50b34d471332fb2d948a75a60

If you ignore the boilerplate code, it maps the xmlsec ECDSA key type to
ecKey, the xmlsec ECDSA-SHA256 combined type to
SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATUR.

If you clone that repo, and built it like (on Linux):

./configure --with-pic --disable-shared --disable-crypto-dl --without-libxslt 
--without-gnutls --without-gcrypt --without-openssl --enable-debugging
make
cd tests/aleksey-xmldsig-01
../../apps/xmlsec1 verify --trusted-der ../keys/cacert.der --enabled-key-data 
x509 enveloping-sha256-ecdsa-sha256.xml

is a reproduce for the problem I have. Here are the details I figured
out so far:

- NSS wants the signature data (64 bytes) as a der-encoded pairs of
   integers, so need to encode them before handing over the SECItem to
   NSS in my client code (the above patch already does that).
- Once this is solved, VFY_EndWithSignature() fails with (end of my gdb
   session):

397 crv = PK11_GETTAB(slot)->C_CreateObject(rwsession,
(gdb)
383 SECStatus rv = SECSuccess;
(gdb)
397 crv = PK11_GETTAB(slot)->C_CreateObject(rwsession,
(gdb)
400 if (crv != CKR_OK) {
(gdb) print /x crv
$1 = 0x130
(gdb) bt
#0  PK11_CreateNewObject (slot=slot@entry=0x6929a0, session=session@entry=0, 
theTemplate=theTemplate@entry=0x7fffd0a0, count=count@entry=7, 
token=token@entry=0,
 objectID=objectID@entry=0x7fffd098) at pk11obj.c:400
#1  0x77675c15 in PK11_ImportPublicKey (slot=slot@entry=0x6929a0, 
pubKey=pubKey@entry=0x6ae8d0, isToken=isToken@entry=0) at pk11akey.c:232
#2  0x7768e872 in PK11_VerifyWithMechanism (key=0x6ae8d0, 
mechanism=, param=param@entry=0x0, sig=sig@entry=0x7fffd2a0, 
hash=hash@entry=0x7fffd280,
 wincx=) at pk11obj.c:736
#3  0x7768e99e in PK11_Verify (key=, 
sig=sig@entry=0x7fffd2a0, hash=hash@entry=0x7fffd280, wincx=) 
at pk11obj.c:690
#4  0x77673722 in VFY_EndWithSignature (cx=0x6a2d70, 
sig=sig@entry=0x7fffd360) at secvfy.c:596
#5  0x00418c31 in xmlSecNssSignatureVerify (transform=0x6ab4d0,
 data=0x6b36c0 
"\257\237\003<\221\301\330X\273J\307?\345n\177e|\254\362\345\242\317v\205\371{C\243\246Q\027\277+\202M\223@4\354{\254\257M@\275\221\215\313Pw\003f_l\031\062Wʼ7\016*ڱ",
 dataSize=64, transformCtx=) at signatures.c:347
#6  0x00443b9a in xmlSecTransformVerifyNodeContent (transform=0x6ab4d0, 
node=, transformCtx=transformCtx@entry=0x7fffd710) at 
transforms.c:1523
#7  0x0044e0f4 in xmlSecDSigCtxVerify (dsigCtx=dsigCtx@entry=0x7fffd450, 
node=) at xmldsig.c:353
#8  0x0040929c in xmlSecAppVerifyFile (filename=) at 
xmlsec.c:1223
#9  0x0040737d in main (argc=7, argv=0x7fffd9e8) at xmlsec.c:1058

0x130 is CKR_DOMAIN_PARAMS_INVALID.

Needless to say, if I do the RSA equivalent of this (the name of the
test file in the same directory is enveloping-sha256-rsa-sha256.xml),
then verification works fine.

Any idea what can be the problem here? At least with the distro-provided
nss (which is build with optimization enabled) I can't step into
C_CreateObject() in gdb.
You would need to install the -debug package for nss-softokn on the 
distro to step into softoken (assuming you aren't using a hardware 
accellerator).


Fortunately you've provided enough information to get an idea of what is 
going on. EC keys have a der encoded parameter telling it what curve the 
key is associated with (generally a der encoded oid pointing to the 
specific curve). The parameter is in the field u.ec.DerEncodedParams, 
and usually applications get this from the spki in a DER certificate, or 
a raw spki encoded structure. You'll need to map the xml way of 
identifying the curve into the der encoding. NOTE: NSS only supports 
what's called the 'named curve' format of the parameters, so if xml is 
using raw curve parameters, then you'll have to map the raw curve 
parameters into known named curves.


bob


But maybe there is something more fundamental here. :-)

If there is anything above that is not enough for reproducing the
problem, please let me know.

Thanks a lot,

Miklos



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS open multiple NSS-Databses at once?

[Robert Relyea]

On 01/10/2017 02:07 PM, Opa114 wrote:

Am Dienstag, 10. Januar 2017 22:24:10 UTC+1 schrieb Robert Relyea:

On 01/10/2017 10:18 AM, Opa114 wrote:

thanks, but these facts i know.
I don't want top let multiple applications open one Database, i want to open 
multiple different Mozilla databases, in the old standard format, with one (my) 
application.

I tried to use the NSS_Init functions. These works with openening one database, 
but when i open a second one the whole application crashes,so that's why i 
asked the question and may be get some working example c++ code?

1) Where are you crashing (it's not expected to work, but I don't expect
a crash because you called NSS_Init again).

2) To open additional databases you want to use SECMOD_OpenUserDB:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/PKCS11_Functions#SECMOD_OpenUserDB

You can call that multiple times.
Once the database is opened any of the NSS find functions will find all
the certs in both databases. The slot returned from SECOMD_OpenUserDB
can be used in functions that take a slot to narrow the operations just
to that particular database.

To NSS each database will look basically like a smart card.

When you are through with that database you can use SECMOD_CloseUserDB()

bob


thanks for reply. Here are first some little code of which did not work, that 
means it crashes:

functionLoadFirefox() {
SECStatus rv = NSS_InitReadWrite(PATH_TO_FF_DB);
... if success load Certificates with PK11_ListCerts(PK11CertListAll, NULL);
NSS_Shutdown();
}

functionLoadThunderbird() {
SECStatus rv = NSS_InitReadWrite(PATH_TO_TB_DB);
... if success load Certificates with PK11_ListCerts(PK11CertListAll, NULL);
NSS_Shutdown();
}

So these are my two functions in which i opened and clos the databases and 
retrieve the certificates.
So the certs you got from the first call is likely preventing 
NSS_Shutdown from completing. The certs hold references to the 
respective slots. Those references prevent NSS_Shutdown from closing 
completely. The will prevent the second NSS_Init from succeeding, so you 
probably crash in your second shutdown. You can detect this happened by 
looking at the return value from NSS_Shutdown().


--> 2) To open additional databases you want to use SECMOD_OpenUserDB
So this means. First i have to call NSS_Init with let's say firefox database ad 
the i have to call SECMOD_OpenUserDB with the thudnerbirddatabse, right? Or 
must i load both with the SECMOD_OpenUserDB?
You can either use NSS_Init with no database and then call 
SECMOD_OpenUserDB() for both, or you can call NSS_Init with one database 
and then call SECMOD_OpenUserDB with the other.


--> Once the database is opened any of the NSS find functions will find all the 
certs in both databases
But i have to know from which databse the certificates are coming from. So i 
need to know that let's say Certificate ABC ist stored inside Firefox Databse 
and Certificate 123 is stored in Thunerbird Database. How can i do that? or is 
this not possible?
The slot the database can be found in the cert->slot entry, but this 
will only give you ONE of the slots the cert lives in. If a cert exists 
in both databases, it will have a single entry on the list and be 
"somewhat" random which slot is listed (If you open one database with 
NSS_Init and the second with SECMOD_OpenUserDB() then the one you opened 
with SECMOD_OpenUserDB() will be the slot that shows up.


To fix this issue, there's a function called PK11_GetAllSlotsForCert() 
which returns a slotList and will return all the slots that hold this 
cert. The slots map one for one to the databases you opened (or any 
smart cards you have loaded). You can control the 'tokenName' of each 
slot with the string arguments you pass to SECMOD_OpenUserDB(), and you 
can get the token name with PK11_GetTokenName() on each slot on the list..


You could also use PK11_ListCertsInSlot() which takes a slot 
(SECMOD_OpenUserDB() will return a slot for you) and lists only those 
certs in that slot.


Be sure to free all these things once you are through with them, or your 
shutdown will fail at the end again.



bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS open multiple NSS-Databses at once?

[Robert Relyea]

On 01/10/2017 01:40 PM, John Dennis wrote:

On 01/10/2017 04:23 PM, Robert Relyea wrote:

2) To open additional databases you want to use SECMOD_OpenUserDB:


Bob, is SECMOD_OpenUserDB new?


No, it's been around for quite some time.


bob

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS open multiple NSS-Databses at once?

[Robert Relyea]

On 01/10/2017 10:18 AM, Opa114 wrote:

thanks, but these facts i know.
I don't want top let multiple applications open one Database, i want to open 
multiple different Mozilla databases, in the old standard format, with one (my) 
application.

I tried to use the NSS_Init functions. These works with openening one database, 
but when i open a second one the whole application crashes,so that's why i 
asked the question and may be get some working example c++ code?
1) Where are you crashing (it's not expected to work, but I don't expect 
a crash because you called NSS_Init again).


2) To open additional databases you want to use SECMOD_OpenUserDB:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/PKCS11_Functions#SECMOD_OpenUserDB

You can call that multiple times.
Once the database is opened any of the NSS find functions will find all 
the certs in both databases. The slot returned from SECOMD_OpenUserDB 
can be used in functions that take a slot to narrow the operations just 
to that particular database.


To NSS each database will look basically like a smart card.

When you are through with that database you can use SECMOD_CloseUserDB()

bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS open multiple NSS-Databses at once?

[Robert Relyea]

On 01/08/2017 05:34 AM, Opa114 wrote:

Hi there,

i have to use NSS in one of my applications and therefor i have to open 
multiple databases (for example Firefox and Thunderbird) at once to read and 
write into these. How can i do this programatically in C++? Some exmaple Code 
would be very helpful because the whole NSS-Stuff is not very well documented.

Thnaks in advice! :)


NSS does have a database format that can allow multiple applications to 
open the same database at the same time, but neither Firefox nor 
Thunderbird has yet moved to that database. It is possible to force them 
to use this database format by setting the NSS_DEFAULT_DB_TYPE to sql. 
Once they are using the same database, you will have to use symbolic 
links so that the NSS databases in the separate firefox and thunderbird 
point to a single database.


https://wiki.mozilla.org/NSS_Shared_DB_Howto explains how to do set up 
the above.


If you have an application, you can open the shared database by passing 
"sql:{shared directory path}" to the configdir parameter of the 
NSS_Initxxx function you are calling to initialize NSS (where {shared 
directory path} is replaced by a path to a common directory you which 
your applications to share. Some recommendations for Linux based 
applications can be found here: 
https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX



bob



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Fwd: debug PKCS11

[Robert Relyea]

On 11/18/2016 12:49 AM, Alexei Mayanov wrote:

Hello! I'm developing PKCS11 library for my device. This library is based
on pkcs11-proxy (https://github.com/SUNET/pkcs11-proxy). It work good with
different apps but with Firefox I can't login with client certificate on to
the test site. Firefox doesn't present me the list of certificates on the
device. I made log of calls of PKCS11 API functions from my library and
can't determine the reason of problem. And I don't know what is happening
inside NSS that cause the problems. Is it possible to enable some debug
info in NSS library that Firefox uses? Thanks in advance!

Hmm,
Have you installed the PKCS #11 module in firefox?

 if not, go to the advanced preferences
   (about:preferences#advanced) and click the 'security devices'
   button, then click the 'Load' button.

If so, Does it show up in the security devices dialog 
(about:preferences#advanced)?


   if not, it means NSS couldn't load your pkcs #11 module, Usually the
   dlopen failed for some reason, though it could be NSS opened the
   module but had some issues initializing it. If you are getting into
   your C_GetFunctionList() function, then the dlopen worked fine. NSS
   will then call C_Initialize(), and then the normal C_GetSlots, etc.

If so, Does it show that the device is present?

   If your module is loaded, it should show the slots in the security
   devices dialog (If not you module did not give NSS any slots). You
   can click on the slots to see the status of each slot. If there is a
   card plugged in, the status should be present. If not the status
   should be not present. If NSS had an error initializing the slot,,
   it should show a status of disabled. The latter means that NSS
   couldn't get everything it needs for the slot to be useful (like
   being able to create a session). Errors here are usually problems
   with session management in the token.

If so Do you get a password prompt for your device if you bring up the 
cert dialog?


   If not (and your token is present), it means that you probably
   didn't make your token as requiring a password properly, or you told
   NSS you were already logged in (again session management). NOTE:
   this may be OK if you don't require a password to find the keys on
   your token. For most tokens, though, this will cause a problem.

If password handling is OK, do you see any certs from your token in the 
cert dialog?


   Be sure to check all the tabs (particularly 'Your Certificates' and
   'Others'). If no certificates are showing up, then there is probably
   something wrong with your C_FindObject* functions. If the
   certificates are showing up under 'Others' and not 'Your
   Certificates', then there is probably something wrong with your link
   of certificates to keys, or your ability to match private keys.
   certificates which have keys associated with them should have a
   CKA_ID attribute with is matches the CKA_ID of the private key
   associated with the certificate. NSS will lookup the CKA_ID from the
   cert and then search for a private key with that same CKA_ID. If it
   finds that key, it will mark it as a 'user' certificate. Only 'user'
   certificates show up in 'Your Certificates' and only 'Your
   Certifcates' are used in ssl client auth operations.


If all this is working, you probably aren't dealing with an issue of 
your module, but a configuration issue with the server and firefox.


Best regards,
Alex



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS_Context and FIPS

[Robert Relyea]

On 10/21/2016 01:59 PM, Rob Crittenden wrote:

Robert Relyea wrote:

On 10/21/2016 07:04 AM, Rob Crittenden wrote:

I'm trying to figure out how to dynamically enable FIPS support for
NSS Contexts.

I started with multinit.c and initialize FIPS right after calling
NSS_InitContext() using this:


So you can't change the state of an already open database. NSS will
switch all new databases that are opened, and idle the old ones
(basically they are open, but not really accessible).




if (!PK11_IsFIPS()) {
fprintf(stderr, "Initializing FIPS\n");
SECMODModule *mod = SECMOD_GetInternalModule();
if (!mod) {
fprintf(stderr, "No module!?\n");
exit(1);
}
char * internal_name = PR_smprintf("%s",
SECMOD_GetInternalModule()->commonName);

if ((SECMOD_DeleteInternalModule(internal_name) != 
SECSuccess) ||

 !PK11_IsFIPS()) {
 fprintf(stderr, "Unable to enable FIPS mode on
certificate database\n");
 exit(1);
}

I'm executing it like this, initializing only db1 and db2 as contexts:


So when you do an initcontext, you're main database is usually not the
same as the main database when you open NSS, so it won't get
automatically switched.

Is there a reason you are trying to do a dynamic switch to FIPS mode
from within a library? (I'd like to know the use case).


I'm converting mod_nss to use contexts. I previously had an option to 
switch on FIPS mode which turned it on in NSS, did some sanity 
checking on the cipher options and required a password.

Did you know if it was used much?


I'd be ok requiring an all or nothing with the FIPS databases if that 
simplifies thiungs.
That's probably the best. NSS allows mixed FIPS/non-fips to a point, but 
really only to add the transition from one to another. Only one is 
usefully active at once.




So things are acting as I would expect. your other lib will likely need
to shutdown it's database and reopen it.


I'm still a little unclear. So if I open all the databases, and THEN 
set FIPS mode, that will do the trick? I was pretty sure I tried that 
but who knows.
No, you need to switch to FIPS mode first. It's the databases that were 
opened before you got into FIPS mode that's the issue.


(NOTE: when you swith from FIPS to non-fips, you are actually switching 
modules. The old modules and their slots hang around only as long as 
there are references to them. Everthing you open before you switch to 
FIPS mode will be on the old module which will go defunct after the switch).




bob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS_Context and FIPS

[Robert Relyea]

On 10/21/2016 07:04 AM, Rob Crittenden wrote:
I'm trying to figure out how to dynamically enable FIPS support for 
NSS Contexts.


I started with multinit.c and initialize FIPS right after calling 
NSS_InitContext() using this:


So you can't change the state of an already open database. NSS will 
switch all new databases that are opened, and idle the old ones 
(basically they are open, but not really accessible).





if (!PK11_IsFIPS()) {
fprintf(stderr, "Initializing FIPS\n");
SECMODModule *mod = SECMOD_GetInternalModule();
if (!mod) {
fprintf(stderr, "No module!?\n");
exit(1);
}
char * internal_name = PR_smprintf("%s",
SECMOD_GetInternalModule()->commonName);

if ((SECMOD_DeleteInternalModule(internal_name) != SECSuccess) ||
 !PK11_IsFIPS()) {
 fprintf(stderr, "Unable to enable FIPS mode on 
certificate database\n");

 exit(1);
}

I'm executing it like this, initializing only db1 and db2 as contexts:


So when you do an initcontext, you're main database is usually not the 
same as the main database when you open NSS, so it won't get 
automatically switched.


Is there a reason you are trying to do a dynamic switch to FIPS mode 
from within a library? (I'd like to know the use case).


Dynamic switching is a pretty careful choreographed dance that 
applications like mozilla can execute with care. It usually involves 
both fips and non-fips tokens opened for a short period until all the 
references can be cleared. Databases opened before the switch will 
almost certainly be inaccessible.


$ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command 
list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly 
--order 12zi


This is the output:

$ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command 
list_certs --lib2_command list_certs  --lib1_readonly --lib2_readonly 
--order  12zi

* initializing with order "12zi"*
*NSS_Init for lib1*
Checking for FIPS
Initializing FIPS
*Executing nss command "list_certs" for lib1*
cacert CTu,Cu,Cu
*   Slot=NSS FIPS 140-2 Certificate DB*
*   Nickname=cacert*
*   Subject=*
*   Issuer=*
*   SN=01 *
Server-Cert  u,u,u
*   Slot=NSS FIPS 140-2 Certificate DB*
*   Nickname=Server-Cert*
*   Subject=*
*   Issuer=*
*   SN=04 *
*NSS_Init for lib2*
Checking for FIPS
FIPS already enabled
*Executing nss command "list_certs" for lib1*
*Executing nss command "list_certs" for lib2*
*NSS_Shutdown for lib2
*Shutdown lib2 state = 0
*Executing nss command "list_certs" for lib1*
*NSS_Shutdown for lib1
*Shutdown lib1 state = 0

So db1 is successfully put into FIPS mode and the slot names are 
changed as one would expect, but then lib2 isn't set into FIPS mode 
and subsequently no certificates are discovered at all (I can only 
assume because there is a mix of FIPS and non-FIPS tokens so it throws 
up?)

yes.


Any idea what I'm doing wrong?

pushing the limits of what is possible;).

So things are acting as I would expect. your other lib will likely need 
to shutdown it's database and reopen it.


bob


thanks

rob



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS db nicknames with NSS_InitContext()

[Robert Relyea]

On 10/18/2016 11:16 AM, Rob Crittenden wrote:
It looks like when multiple NSS databases are initialized using 
NSS_InitContext() the nicknames can take multiple forms depending on 
order of initialization. Using the multinit program and three NSS 
certificate databases with identical nicknames I saw the following 
names associated:


(first initialized) Server-Cert
(second initialized) NSS Certificate DB:Server-Cert
(third initialized) NSS Application Token 0005:Server-Cert

Is this expected/dependable behavior?

Short answer: yes.

So the first and second are identical (assuming your built in database 
is named 'NSS Certificate DB'). The name would be different yet in FIPS 
mode, and different if NSS is initialized by the application with it's 
own database name.


What is happening is the actual token name is different. When NSS is 
first initialized, it initialized with it's default token, which doesn't 
need a separate 'token' identifier. If you call InitContext() again with 
the same database, it will 'point' to the already opened database. If 
you point to a different database, you will get a new token with it's 
own name.


It sorta looks like with that third initialization it also has each of 
the previous two nicknames as well.


If you are using the same cert in all three cases (and the token is 
still open), All three nicknames will point to the same cert. It looks 
like one cert that lives in 3 different tokens. (There's a call that 
will give you all the tokens the cert lives in).


It seems like rule of thumb is that using multiple databases with the 
same nicknames is a terrible idea and unpredictable, just looking for 
confirmation.


So because of historical issues, nicknames will often give you 
unpredictable results. I usually recommend other ways to finding your 
cert (like recording the issuer/SN to use).


bob


thanks

rob



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: JSS/NSS locks my smart card after 1 bad pin entry

[Robert Relyea]

On 10/07/2016 06:56 PM, Ernie Kovak wrote:

Hello -

We're using JSS4 and NSS 3.24 with an OpenSC module to interact with a DoD CAC. 
CACs will lock after 3 consecutive bad PIN entries. We're finding that if the 
user enters a bad PIN even once, that hard limit is exceeded and the card is 
locked.
What version of openSC are you using. OpenSC only recently got CAC 
support added to it.


Have you tried coolkey?


I've searched through NSS to see if there's PIN retry logic, but I didn't see 
anything, though I quickly got lost in the code so not sure. I'm a java dev...


NSS itself does not retry bad pins, but it does present the application 
the opportunity to retry the pin. It has a flag so applications that 
cache the pin can know to discard the cached pin on retry. It could be 
an error in the JSS pin handler?


Is anyone else running a configuration like this that's seeing this behavior? 
Is there a configuration item that might limit the retries?

Thanks!
Ernie



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: modutil add module "ActiveClient" gives error "error 193" (win10)

[Robert Relyea]

On 08/03/2016 12:30 AM, Marjan Savli wrote:

I would like to simplify adding USB ActiveClient Reader into Firefox on
win10.
I already managed to make a batch file to simplify importing our 6
certificates into Firefox.

Manually I would do this step by step after this manual: https://www.
creaplus.si/faq/72-activclient-v-brskalniku-firefox
And if I manually add acpkcs211.dll the result is:

=
bin\modutil.exe -dbdir %Mapa% -list

Listing of PKCS #11 Modules
---
   1. NSS Internal PKCS #11 Module
  slots: 2 slots attached
 status: loaded

  slot: NSS Internal Cryptographic Services
 token: NSS Generic Crypto Services

  slot: NSS User Private Key and Certificate Services
 token: NSS Certificate DB

   2. ActiveCard
 library name: C:\Program Files\ActivIdentity\ActivClient\acpkcs211.
dll
  slots: There are no slots attached to this module
 status: Not loaded
---
=


But when I try the same action with modutil, the result is "error 193".

=
bin\modutil.exe -dbdir %Mapa% -add "ActiveClient" -libfile "c:\Program
Files\ActivIdentity\ActivClient\acpkcs211.dll"

WARNING: Performing this operation while the browser is running could cause
corruption of your security databases. If the browser is currently running,
you should exit browser before continuing this operation. Type
'q ' to abort, or  to continue:

Using database directory
C:\Users\UserUE\AppData\Roaming\Mozilla\Firefox\Profiles\ib42fuyl.default...
ERROR: Failed to add module "ActiveClient". Probable cause : "error 193".
Weird 193 isn't an NSS error. NSS errors are all negative and quite 
large (like -8120). The string is coming from PR_Error(), so it may be 
an NSPR error trying to load the library, or a libc error NSPR is 
passing off to us that it can't translate.


The syntax looks fine. It looks like it looks like it's getting the 
correct database.  (I'm presuming you aren't trying to add it to a 
database you've already added). I wonder if the tools are choking on the 
windows '\'. They shouldn't, but it's possible. Maybe try using unix 
style '/'.?


bob

=

I can not find any description of this error.
Some help is appreciated.
Thanks.

   Marjan   --






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Replacement for PK11_GetLowLevelKeyIDForCert etc

[Robert Relyea]

On 06/24/2016 06:29 PM, Andrew Cagney wrote:

Hi, according to the NSS documentation, the functions for getting
CKAIDs are deprecated vis:

/**
  * New functions which are already deprecated
  **/
SECItem *
PK11_GetLowLevelKeyIDForCert(PK11SlotInfo *slot,
 CERTCertificate *cert, void *pwarg);
SECItem *
PK11_GetLowLevelKeyIDForPrivateKey(SECKEYPrivateKey *key);

I'm just wondering what I should be using instead?
What are you after? They are deprecated mostly because they provide 
access to low level PKCS #11 values.

 If you are after the actual PKCS #11 CKA_ID attribute then you could use:

PK11_ReadRawAttribute() for the key. Unfortunately useing 
PK11_ReadRawAttribute() for cert doesn't work yet, but could be added.


bob



Andrew

PS: What does CKA actually stand for :-)

CryptoKi Attribute All PKCS #11 attributes start with CKA_ .




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.24 Release

[Robert Relyea]

On 05/22/2016 04:26 PM, Paul Wouters wrote:

On Sun, 22 May 2016, Kai Engert wrote:


Subject: [ANNOUNCE] NSS 3.24 Release


* NSS softoken has been updated with the latest NIST guidance (as of 
2015)


What does this relate to? Do you have the specific FIPS publication?
Is this perhaps the GCM IV handling?
Checking library integrity at library load time rather than first init 
time. I don't have the document.:(,


bob


Paul





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: RFC7512 PKCS#11 URI support

[Robert Relyea]

On 04/07/2016 05:13 PM, Julien Pierre wrote:

David,

On 4/7/2016 15:49, David Woodhouse wrote:

On Thu, 2016-04-07 at 05:01 -0700, Julien Pierre wrote:

The problem really stems from the design of NSS, specifically the
CERTCertificate*, which maps to a unique DER encoded cert, but not to
a single PKCS#11 object in a single token. Since the same cert can
exist in multiple tokens, but there can only be one CERTCertificate*
pointer for all of them, the only way to resolve the issue would be
for the lookup function to return something other than just
CERTCertificate* alone. PK11_ListCerts does that.

Hm, I thought PK11_ListCerts tried to eliminate duplicates too, which
is why it has that crappy O(n²) behaviour? Does it *really* return more
than one of the 'same' certificate? Don't you *still* get a randomly-
chosen one with unpredictable contents of cert->slot?

It depends on the argument to PK11_ListCerts .

typedef enum {
 PK11CertListUnique = 0, /* get one instance of all certs */
 PK11CertListUser = 1,   /* get all instances of user certs */
 PK11CertListRootUnique = 2, /* get one instance of CA certs 
without a private key.

  * deprecated. Use PK11CertListCAUnique
  */
 PK11CertListCA = 3, /* get all instances of CA certs */
 PK11CertListCAUnique = 4,   /* get one instance of CA certs */
 PK11CertListUserUnique = 5, /* get one instance of user certs */
 PK11CertListAll = 6 /* get all instances of all certs */
} PK11CertListType;

The cert->slot is still random.
Well it's not exactly random. It's the first token referenced unless 
that token is the internal token. Then its the next token referenced. If 
the cert->slot is the internal token you can be sure that the cert is 
only in the internal token.


But you will get multiple cert list entries with the same 
CERTCertificate*, but a different appData, if you use the value that 
don't have "Unique" in the name.

Julien is exactly right here.



OK, but you have the cert in your hand; it doesn't matter where it came
from as long as it's the right one. Hell, in OpenConnect I support
modes where the cert is in a file and only the key is in PKCS#11 or
TPM. Who *cares* where the cert came from?

It's only the *key* which really needs to be found in the right place,
since you have to *use* it from there, right?
In theory, yes, the slot for the key is what matters. The problem is 
if you use cert->slot to look for the key (or even a NULL slot, to 
search all slots).
The key doesn't accept NULL. I think cert->slot will usually get you to 
the key if it exists. If you are worried you can use 
PK11_GetAllSlotsForCertificate() and search for them all.
You might end up with the "wrong" key object. Unlike for 
CERTCertificate, identical keys in multiple tokens don't share a 
single SECKEYPrivateKey object.
No, but the all the keys should match the CERTCertificate. The more 
likely failure is one token has the cert but no key for it.
Of course, since the private key may not be extractable, it's not 
really possible to compare private keys between tokens. But you could 
match them by public key.


If they match the cert, they should be identical (functionally) since 
they must match the public key in the cert or nothing works;).


Upshot: if you are in a case where you care which token the key is in, 
then you use that token throughout. If you just looked up the cert and 
are looking for the key.




I believe there can be multiple SECKEYPublicKeyStr objects also, even 
if they are identical public keys, but not 100% sure.


Yes, they are usually generated on the fly and destroyed. They aren't 
reference counted like the certificates.



bob



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: RFC7512 PKCS#11 URI support

[Robert Relyea]

On 04/07/2016 03:49 PM, David Woodhouse wrote:

On Thu, 2016-04-07 at 05:01 -0700, Julien Pierre wrote:

The problem really stems from the design of NSS, specifically the
CERTCertificate*, which maps to a unique DER encoded cert, but not to
a single PKCS#11 object in a single token. Since the same cert can
exist in multiple tokens, but there can only be one CERTCertificate*
pointer for all of them, the only way to resolve the issue would be
for the lookup function to return something other than just
CERTCertificate* alone. PK11_ListCerts does that.

Hm, I thought PK11_ListCerts tried to eliminate duplicates too, which
is why it has that crappy O(n²) behaviour? Does it *really* return more
than one of the 'same' certificate? Don't you *still* get a randomly-
chosen one with unpredictable contents of cert->slot?


No, there is only one cert no matter how many tokens that cert exists in.

cert->slot points to either the internal token (if the cert doesn't 
exist in a removable slot), or the first PKCS #11 removable slot. There 
is a call: PK11_GetAllSlotsForCert() which will return a slotlist of all 
the slots that certificate lives in.



Hm, purely for finding the *cert*, why doesn't the token: prefix
resolve that?

The token: prefix is only used as a starting point for the lookup.
But if the same DER cert exists in multiple tokens, then the value of
CERTCertificate->slot pointer is unpredictable.
It may or may not match what was used during the lookup. Same issue
for the nickname field.


It doesn't really work like that Julian. There is only one cert, the 
slot value is the same for all certs no matter how you looked it up. 
There is no guarantee that the token: value will map to the same slot as 
cert->slot.


In practice the number of times you have the same certificate on more 
than just the internal token and one other slot is exceedingly rare. 
That is the only reason the current code works at all.



OK, but you have the cert in your hand; it doesn't matter where it came
from as long as it's the right one. Hell, in OpenConnect I support
modes where the cert is in a file and only the key is in PKCS#11 or
TPM. Who *cares* where the cert came from?

It's only the *key* which really needs to be found in the right place,
since you have to *use* it from there, right?


This is correct. This is exactly how it works in NSS. NSS knows how to 
search all the slots the certificate lives on to find the related key.



Basically, what it comes down to, is that if you use the following
sequence :
cert = PK11_FindCertFromNickname("token:subject")
key PK11_FindKeyByCert(cert);

Your cert and key may not match the "token" in the original lookup
string. cert->slot and key->slot may not match.


There isn't  a PK11_FindKeyByCert. There is a 
PK11_FindPrivateKeyFromCert and it takes a slot from the caller, not 
from cert->slot.



bob



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: RFC7512 PKCS#11 URI support

[Robert Relyea]

On 04/04/2016 03:19 PM, Ryan Sleevi wrote:

On Mon, Apr 4, 2016 at 12:39 PM, David Woodhouse  wrote:

We usually reserve the term "breaks the API" for when something *used*
to work, and now doesn't. Not when a previously-failing call now
actually does something useful.

No, sorry David, that's not how we've done stuff in NSS.
I think I would push back on this a bit. David change is very close to 
other changes we've made in the NSS API, in fact this very API. This API 
originally only took a nickname. The token: was an extension added in 
such a way that existing applications that knew nothing about token: 
could still function.


It was purposefully done so that applications that simply passed through 
the nickname from the command line or from the user would get access to 
the new functionality.


When it has an observable difference, when it breaks the contract
previously provided, we prefer not to do so.

I would disagree it breaks the contract.

I'm presuming the issue here is that you are screening nicknames to 
prevent certain nicknames from being accessed. That presumably means you 
are restricting nicknames to certain tokens? since pkcs11 is not a valid 
token, it would not be in our allow list.


In general I wouldn't recommend using a nickname filter to restrict 
access to certain certs, I'm pretty sure I can break out of any such 
filter you set up with the existing code.


This code wouldn't affect filters on nicknames for object creation.

I think rather than arguing from first principles (because you aren't 
getting any agreement that the priniciples you are starting from are the 
same ones the rest of us are seeing, let's just have an concrete example 
of a broken case in your existing filtering code where would be fooled 
into allowing something it didn't want to allow once this change is made.


bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS_NoDB_Init(".") and FIPS mode

[Robert Relyea]

On 03/18/2016 01:55 PM, Wan-Teh Chang wrote:

On Fri, Mar 18, 2016 at 10:49 AM, Robert Relyea  wrote:

Yes, SECMOD_DeleteInternalModule() is a toggle which switches NSS between
FIPS and non-FIPS. If you don't have a database open, or the database is
open readOnly, the change only affects the running program.

Hi Bob,

Your answer surprised me. The latest NSS FIPS 140-2 Security Policy at
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2564.pdf
says user passwords are stored in salted form in the key database
(Table 8 on page 26). So I don't understand how NSS can operate in
FIPS mode without an NSS database. I guess without an NSS database the
NSS crypto module will only provide services that don't require user
authentication, such as hashing and random number generation?
The new softokn allows you to run in level 1. If you don't have a 
database, or the database is set without a password, then NSS is running 
in FIPS-140 Level 1 mode and does not require a password.


This allows NSS to run in fips mode based on a system FIPS flag (which 
linux has) without massive breakage. If you need level 2 however, you 
must have a database and you must set the password. NSS will allow you 
to switch from level 1 to level 2, but not vice versa.


bob


Thanks,
Wan-Teh Chang





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Programmatically smartcard/token access with NSS

[Robert Relyea]

On 03/17/2016 06:17 AM, Túlio Gomes wrote:

Hello, i need to access a smartcard for signing documents with the private key 
stored inside it.
The idea is to create a c++ component that will be used with a pnacl module 
inside chrome's browser.

So i decided to use NSS, but i'm confused about what steps i need to do for 
load the smartcard, access the private key, sign and verify the document.

I read almost all the existing documentation and didn find any sample to do 
that.

So, here's my code:

int main(int argc, char** argv) {
SECMODModule *module;
SECStatus rv;
static char moduleName[] = "library=libwdpkcs_icp.so 
name=Token-libwdpkcs_icp";

module = SECMOD_LoadUserModule(moduleName, NULL, PR_TRUE);

if(!module) {
fprintf(stderr, "fail to load module");
exit(1);
}

PK11SlotInfo* slot = PK11_GetInternalSlot(); //didnt work. Returns 
nothing (0x0);

You need to initialize NSS itself first.


/*
*  Ok, i load the module. What's next? I need to create a DB or i can 
access the token directly? If so, how can i do this?
*  Probably the next step is to get the slot info. But how?
*/


Once you do this, the token certs are available with any db certs that 
you may already have. Typically in NSS you look up the certs you are 
interested in. 'User' certs are certs with private keys associated with 
them. Once you select a cert, you can lookup the key. The you can use 
that key to sign, decrypt or unwrap. If the cert and key you select are 
in the token, NSS will use it.


You can find an example for decrypting here:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/nss_sample_code/NSS_Sample_Code_sample4

In this example, the cert is found with:
  cert = PK11_FindCertFromNickname("TestCA", NULL);

You can find the cert using on a smartcard with "tokename:certname" as 
the nickname.

If you create a database:
   mkdir ./certs
   certutil -N -d ./certs
use modutil to add your smart card
   modutil -add Token-libwdpkcs_icp -lib libwdpkcs_icp.so -dbdir ./certs
You can then list all the certs on your smart card with
certutil -L -h all -d ./certs
 (you'll be prompted for the pin for your smartcard).

You can also use
 PK11_ListCertsInSlot() to find all the certs on your smart card.
You can use PK11_FindSlotByName() or PK11_FindSlotsByNames to find 
the slot for your smart card.


/usr/include/nss3/pk11pub.h has a list of most of the functions that 
deal with smart cards.



**NOTE*** In the example, you'll need to fix the password function to 
actually prompt for the password. If you don't, you can lock your token 
if it has a fixed numbers of retries.


bob

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/nss_sample_code/NSS_Sample_Code_sample4

SECMOD_DestroyModule(module);
}

Can anyone give me some help?
Thanks in advance.
ps: sorry for my english





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS_NoDB_Init(".") and FIPS mode

[Robert Relyea]

On 03/18/2016 09:14 AM, Andrew Cagney wrote:

Is it possible to put NSS (softtoken) in FIPS mode (PK11_IsFIPS()) without
a "modutil -fips true" database?

By FIPS mode I guess I really mean confirm that NSS has performed some sort
of FIPS self-check.

An earlier thread mentioned some way of toggling things using
SECMOD_DeleteInternalModule()?
Yes, SECMOD_DeleteInternalModule() is a toggle which switches NSS 
between FIPS and non-FIPS. If you don't have a database open, or the 
database is open readOnly, the change only affects the running program.


bob


Andrew





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: server-side OCSP stapling

[Robert Relyea]

On 03/01/2016 02:19 PM, Martin Thomson wrote:

AIUI,  support for stapling in NSS is pretty primitive. You are expected to
make the OCSP query yourself and use the API to configure the server.


IIRC the API to fetch the ocsp response is mostly application code. NSS 
has a simple http request function that can fetch the request if the 
application doesn't supply one (which doesn't know about proxies, etc.). 
You could override the http fetch function, then validate your cert 
change and squirrel way the OCSP response before you pass it off to NSS. 
That's probably the simplest way of getting it.


I think You just need the blob, not the parsed blob.

bob

On Mar 2, 2016 7:42 AM, "Rob Crittenden"  wrote:


I don't see a way to implement OCSP stapling on the server side.

SSL_SetStapledOCSPResponses() is I think what one would use to set the
response in the SSL session but I don't see a way to get the response
from the OCSP handler. At least, I don't see a way without implementing
my own status checker and overriding statusConfig->statusChecker ala
CERT_EnableOCSPChecking().

Am I missing something?

thanks

rob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Using NSS in FIPS mode

[Robert Relyea]

On 01/22/2016 06:42 AM, jonetsu wrote:

Robert Relyea wrote:


The call PK11_IsFIPS() returns true if softoken is in FIPS mode. The
dance to programatically is to call SECMOD_DeleteInternalModule(),
which toggles the module between FIPS and non-FIPS modes.

Thanks.  I will try it.

When are the self-tests run, from an application perspective ?  I presume
they are when FIPS mode is put in effect using modutils. Would that be the
only time they are run ?  For instance, would they be called before
returning from PK11_IsFIPS() ?  Is there a way to force-run those self-tests
from an application ?

That answer is a little different depending on version.

In RHEL 5, 6, and 7:

They are ran when softoken is loaded (whether or not NSS is in FIPS 
mode). If NSS returns PK11_IsFIPS = true, you can know that the post 
tests ran successfully at library load time. Failure of the post tests 
will prevent the softoken from initializing in FIPS mode, which will 
prevent NSS_Initialize (in all of it's flavors from initializing).


Eventually this code will be pushed upstream and will wind up in Fedora.

Currently upstream and they way it used to work in RHEL:

It was ran at C_Initialize time, which happens at NSS_Initialize. If NSS 
isn't in FIPS mode, switching to FIPS mode will cause the code to run 
immediately.


On RHEL 7, NSS looks at the system flag for FIPS mode. If the system is 
in FIPS mode, NSS will force softoken to be in FIPS mode even if it 
would not have been otherwise. If the system is not in FIPS mode, NSS 
softoken can still be placed in FIPS mode with it's traditional switch.


The main difference between FIPS mode and non-FIPS mode for softoken 
actually involves Level 2 issues. CPS are not allowed to leave softoken, 
so calls that extract keys (for instance) will fail. The token also 
requires authentication whenever to do an operation that accesses CPS's 
(like encrypt/decrypt/hmac/sign). So if the browser is in FIPS mode, it 
will authenticate to the database before it does a simple SSL operation, 
for instance, even though you may not be accessing private keys.





Firefox has a button to flip to FIPS mode.

I should have mentioned that the application is in C and is by no way
related to Firefox.
I just meant that Firefox has code you can look at to switch into FIPS 
mode as an example.


Comments much appreciated, cheers.




--
View this message in context: 
http://mozilla.6506.n7.nabble.com/Using-NSS-in-FIPS-mode-tp350446p350498.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Using NSS in FIPS mode

[Robert Relyea]

On 01/21/2016 07:33 AM, jonetsu wrote:

Hello,

Please let me know if this is not the right place to ask about the
following...

This is the right place.


I am new to NSS and would like to use it in FIPS mode.  I do know
about OpenSSL and GnuTLS, both of them having explicit calls to
enabled FIPS mode.  With NSS, so far I have seen that the modutil
non-programmatical utility is used to set FIPS mode, as in:

% modutil -force -fips true -dbdir 

How does an application assures that NSS is in FIPS mode ?
FIPS is a mode in softoken. Usually when softoken is in FIPS mode, NSS 
itself is said to be in FIPS mode.


The call PK11_IsFIPS() returns true if softoken is in FIPS mode. The 
dance to programatically is to call
SECMOD_DeleteInternalModule(), which toggles the module between FIPS and 
non-FIPS modes.

  Are calls
such as sftk_fipsCheck() and sftk_fipsPowerUpSelfTest() in the
softtoken module (fipstokn.c) available to applications ?

No.


What is the behaviour of NSS if an application tries to use a
non-approved algorithm ?
Currently NSS does not restrict you from using non-approved algorithms. 
Officially going to FIPS mode requires the application to turn off any 
uses of non-FIPS algorithms itself. In the SSL code the 
SSLCipherSuiteInfo includes an isFIPS bit applications can use to 
manually turn off non-FIPS algorithms.


Finally, is there any example code out there that uses NSS in FIPS
mode ?
Firefox has a button to flip to FIPS mode. For the most part the only 
issue applications may have in FIPS mode is if the application tries to 
access key material directly (or if the application doesn't handle 
authentication well). An Example of going into FIPS mode can also be 
found in the nss source tree under the cmd/modutil directory.


bob


Any comments, suggestions appreciated, thanks.





--
View this message in context: 
http://mozilla.6506.n7.nabble.com/Using-NSS-in-FIPS-mode-tp350446.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Algorithms supported in NSS 3.17, FIPS mode

[Robert Relyea]

On 12/14/2015 05:04 PM, Paul Wouters wrote:

Don't know about DRBG, but everything else you asked for is supported.

Sent from my iPhone


On Dec 14, 2015, at 18:03, jonetsu  wrote:

Hello,


I am trying to get a list of the algorithms and ciphers supported by NSS 3.17 
in FIPS mode.  Not easy.  Whereas OpenSSL and GnuTLS lists them at run-time, no 
such thing seems to exist for NSS (correct me if I'm wrong).  Is there then a 
document, validation certification, that would list them ?  More to the point, 
I would like to know if AES in CBC mode is supported (128 and 256), AES in GCM 
mode (also 128 and 256), SHA1 and which SHA2, and hash-based DRBG.
DRBG is also supported. NSS only supports hashed based DRBG for it's 
random function (whether in FIPS mode or not).


bob



Any information much appreciated, thanks.





--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: AES-256 vs. AES-128

[Robert Relyea]

On 11/30/2015 12:07 PM, Julien Vehent wrote:

On 2015-11-30 12:47, Robert Relyea wrote:
I've always found the 128 bit prioritized over 256 a silly 
recommendation, I support reordering.


Can you expand on why you think it is silly?


The argument went that 128 bit was 'sufficient' and there was a 
performance 'hit' doing 256. Sufficient changed our criteria from 
objective (stronger first, then performance) to subjective (random 
definition for sufficient). At one point DES 56 was considered 'sufficient'.


The case in point, we've subjectively decided 128 bit isn't sufficient. 
That was highly predictable (attacks get better, the subjective line 
will move again).


At Red Hat, we've already reordered this. We were having problems 
connecting to servers who had the following logic: SSL connect to 
client. Check to see if the key strength was sufficient. If not display 
an error message through the SSL connection. The server was assuming if 
a client connected with a 128 cipher, then it must not be able to do a 
256 bit cipher because why would it prioritize 128 bits over 256 bits? 
The server didn't turn off the weaker ciphers because the server wanted 
to give the weaker clients a reasonable error message.




The original thread [1] had a long discussion on this topic. 


Yes, which is why I didn't push it. I gave my reasons for disagreeing. 
They weren't accepted. I saw no reason to get religious about it. Still 
didn't mean I didn't think the decision was silly. I find life goes 
better if you only fight against patently wrong decisions and let silly 
ones go with just giving notice.


bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: AES-256 vs. AES-128

[Robert Relyea]

On 11/25/2015 02:01 PM, April King wrote:
My colleague Julien Vehent and I are in the process of updating the 
Mozilla Server Side TLS documentation:


https://wiki.mozilla.org/Security/Server_Side_TLS

One of the topics of conversation was whether or not the Modern TLS 
configuration should prefer AES-256 over AES-128.  Recently, there has 
been some doubt cast over the security of AES-128, between posts by 
security researchers like djb, as well as the recent decision by the 
NSA to recommend AES-256 over AES-128, due to its increased resistance 
against quantum cryptography:


http://blog.cr.yp.to/20151120-batchattacks.html
https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml


I've always found the 128 bit prioritized over 256 a silly 
recommendation, I support reordering.


bob


The general consensus was to bring the conversation to the 
dev.tech.crypto group prior to updating the standards either way. 
There hasn't been any claim that AES-128 is actually broken, but the 
idea behind the Modern guidelines is to stay ahead of the 
cryptographic research curve.  One thing to keep in mind is that the 
Modern guidelines are intended for modern systems that don't require 
any kind of backwards compatibility or necessarily need to be friendly 
towards old, underpowered systems (such older smartphones).


For reference, this is the current state of preference order for the 
four major browser manufacturers:
Firefox: AES-128-GCM > AES-256-CBC > AES-256-CBC (doesn't include 
AES-256-GCM in list of cipher suites)
Chrome: AES-128-GCM > AES-256-CBC > AES-128-CBC (also does not request 
AES-256-GCM)

Safari: AES-256-GCM > AES-128-GCM > AES-256-CBC > AES-128-CBC
Edge: AES-256-GCM > AES-128-GCM > AES-256-CBC > AES-128-CBC

Proposal for Modern:
AES-256-GCM > AES-128-GCM > AES-256-CBC > AES-128-CBC

If the general agreement is to move Modern to AES-256, it may also be 
worthwhile considering whether or when we move that recommendation 
down to the Intermediate level, which is intended for general purpose 
websites that don't have a need for backwards compatibility with very 
old clients (such as IE6/Win XP SP2).







smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Add New OID to NSS

[Robert Relyea]

On 11/04/2015 11:21 AM, JBarry wrote:

Hi Bob,

Thank you for the helpful reply. I have looked at the files you have
mentioned and am a little confused about something.

For example (secoid.c lines 34-35):
/* USGov algorithm OID space: { 2 16 840 1 101 } */
#define USGOV   0x60, 0x86, 0x48, 0x01, 0x65

In this snippet, the OID appears to be 2.16.840.1.101. However, the hex
translation does not equal the decimal string because 0x60, 0x86, and 0x48
do not translate to 2, 16, 840 respectively, but 0x1 and 0x65 do convert to
1 and 101. Clearly I am missing something here  in how to convert between
the two.

I am also waiting to hear back from my supervisor as to whether or not I can
disclose the OID and its purpose.

Thanks again,
Jim
The oid is encoded according to DER rules for encoding oids. In general 
the first 2 bytes encode to a single byte, and bytes under 128 encode to 
themselves.


Microsoft had a decription here: 
https://msdn.microsoft.com/en-us/library/windows/desktop/bb540809%28v=vs.85%29.aspx
A program which does it can be found here: 
http://www.rtner.de/software/oid.html (I have not verified the program 
myself).


bob




--
View this message in context: 
http://mozilla.6506.n7.nabble.com/Add-New-OID-to-NSS-tp346875p346880.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Add New OID to NSS

[Robert Relyea]

On 11/04/2015 08:57 AM, JBarry wrote:

Hello,

I'll apologize in advance if this question has already been asked/answered
(I did look and found nothing that helped me out) or if the question seems
trivial. I am a college intern currently working with NSS for the first
time, so please forgive me if I state anything incorrectly or in a confusing
manner.
  
So I have created a key/certificate using OpenSSL and am trying to import it

into the NSS database. However, this is failing because we are using a local
algorithm that NSS (and pk12util) does not recognize. I need to add the OID
to NSS in order for it to recognize the algorithm we are using, but I am
unsure of where to do this. I have scoured the code and have looked in a
bunch of files (some of which contain OID "definitions"), but I cannot
figure out how to add the OID to make the import process work.

Any help would be greatly appreciated,
Jim


The oids are in the oid table found in secoid.c, and defines are in 
secoidt.h. The table is a static array of SECOidData called 'oids'.

You'll need to add new entries at the bottom. with the OD() macro.

The parameters of the OD macro are:
   1) CONST_OID (basically an array of bytes) of the encoded oid 
representation. (so '2.16.1.101' is 0x60, 0x86, 0x48, 0x01, 0x65). You 
declare a CONST_OID in the block above the table with  a name 
representing your new oid (this value is private to this function. There 
are already macros for several  common spaces (like PKCS5 or ANSI_X962).
   2) The NSS OIDTag. This is the name NSS applications use to 
reference the tag. You also need to add this to the SECOidTag enum in 
secoidt.h. The oid tag value should equal the index into the oids[] 
table. NSS checks this at runtime.

   3) A string decryption of what the oid represents.
   4) The PKCS #11 mechanism value that this oid maps to. If there 
isn't a PKCS #11 mechanism, then this value should be 
CKM_INVALID_MECHANISM. For pkcs12 there should be a corresponding PKCS 
#11 mechanism.

   5) The Certificate extension value. It should be one of the following:
SUPPORTED_CERT_EXTENSION - this oid is a certificate extension 
that is recognized an parsed by the NSS chain validation code.
FAKE_SUPPORTED_CERT_EXTENSION - treat the extension represented 
by this oid as a recognized extension if NSS_ALLOW_UNSUPPORTED_CRITITCAL 
is set. If NSS_ALLOW_UNSUPPORTED_CRITICAL is not set, then it is treated 
as UNSUPPORTED.
UNSUPPORTED_CERT_EXTENSION - this oid represents an extension 
which is not recognized. certs with this extension that are marked 
critical should fail certificate validation.
 INVALID_CERT_EXTENSION - this oid is not a certificate 
extension oid, don't treat is at one.


This will make the oid recognizable, it does not mean that the oid will 
be properly handled by the underlying code.


What is the actual oid you want to add and what does it represent?

bob






--
View this message in context: 
http://mozilla.6506.n7.nabble.com/Add-New-OID-to-NSS-tp346875.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to access certs in the Windows keystore from Java?

[Robert Relyea]

On 10/07/2015 10:45 AM, merlin.w.vinc...@gmail.com wrote:

Maybe my googling skills are weak, but I found no information on how to get NSS 
to use keys from the Windows keystore. In the end, I decided it's probably a 
violation of the NSS paradigm anyway. It seems the intent is to use the NSS 
database as the sole repository of certs and keys. Especially in FIPS mode.

If that's not correct, I would love to know how to do that. Anyone?

So, once I used pk12util to import a p12 into NSS I was able to get 2-way SSL, 
or client-authenticated SSL, to work using the javax.net.ssl classes. That is, 
configure the NSS provider as described in the Java 8 docs referenced above 
then build an SSLContext and so on, as usual.

Now my problem is how to choose among multiple certs. If there's more than one 
cert that matches the server's set of issuing CAs, the system just picks the 
first one.


The key store is just another pkcs11 module. There's an old sample pkcs 
#11 module I wrote for capi that's in the nss ckfw directory, though 
it's probably bitrotted. At the time I had no problem accessing certs 
and keys in the windows key store. helpcrypto has pointed out another 
one which is probably newer and better maintained.


bob


If I try to provide my own KeyManager so I can override its chooseClientAlias 
method I get an error:

java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may 
be used

Is there any way around that?

Thanks!
Merlin





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Robert Relyea]

On 09/25/2015 09:13 AM, Erwann Abalea wrote:

Le vendredi 25 septembre 2015 14:39:04 UTC+2, helpcrypto helpcrypto a écrit :

On Fri, Sep 25, 2015 at 11:52 AM, Erwann Abalea  wrote:

[...]

Although it won't solve my problem, this will make possible to kill
signature applets forever, which indeed it's my real objective.

This objective will soon be reached. Java isn't supported anymore in Chrome 45 
and is supposedly to be deprecated in Firefox soon, and ActiveX (whence Java 
also) won't be supported in Edge.
I thought helpcrypto was suggesting using a javacard applet, not java 
that runs on the client. Of course to install a javacard applet you need 
the card keys, which I believe he said he didn't have.


bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Robert Relyea]

On 09/25/2015 01:36 AM, helpcrypto helpcrypto wrote:

Hi all


I hope you can find a solution for my problem, cause I can't. (And perhaps
it's impossible)


Based on my knowledge of PKCS#11 standard, the spec is exposed to a MITM
attack that steals the PIN when an application invokes C_Login against a
PK#11 library.


While using CryptoAPI it's the system who shows the "PIN dialog" making it
harder to crack/extract the PIN, C_Login function receives the PIN in
plaintext, and "an evil software", like PKCS11SPY, could get access to it.

Sadly, using Pinpads is out of scope/beyond our possibilities.
While dialog pin prompts don't really help all that much (if the 
attacker has your machine, they can pop up their own dialogs, just 
because the PKCS #11 software enforces a login, doesn't mean that the 
cards do. At the bottom the application can always talk directly to the 
card).


If you want dialog pin prompts, you can always just use protected pin 
path tokens, but then your application will only work with protected pin 
path tokens.


If your machine is compromised to the point that the attacker can insert 
PKCS11SPY into your PKCS #11 chain, there's very little you can do.




Of course my app could check pkcs#11 library checksum and other mechanisms
to "ensure" it is the library and not a proxy, but if my application is
opensource (I'll love to), I'm fu*ked.


Open source doesn't make this any worse, your proprietary app can be 
changed to accept the new checksum, or skip the checksum step 
altogether. In order to proxy PKCS #11 this way you need to be able to 
install a PKCS #11 module that does the proxying.


Is there any way to "trust" in the client? Can the server know the exe
being executed is MY exe and an EVIL copy? (A private key embebed can also
be cracked!)


Short answer: No. Long answer: The best you can do is under certain 
conditions the server can know the authentication key is in a token, but 
only if the server is part of the infrastructure that issued the cert 
and key and performed the appropriate checks to verify the key is in the 
token (and only in the token).





Furthermore, our *lovely* card sends APDU for login in plainText, so anyone
could see "1234" easily. And we are not able to establish a secure channel
cause we lack the required keys.
Every card does that. The connection between the computer and the reader 
is considered 'secure'.


bob



Seems what I really need is something like a Javacard applet with an
embebed "server public key", a component certificate and a session keypair
for mutual authentication and cipher communications between server and
client, but we aren't able to load this applet on the Card.


You'd need your own protocol for this. Card management systems usually 
do this with their own protocol where the server talks to the card 
directly through a global platform secure channel. This only works 
because the server is part of the trusted base for the card management 
system (e.i. the server knows the keys that even the user doesn't know 
for his card). Even then, you don't know that the user saw want 
documents he thinks he's signing because in your scenario the client 
computer is fundamentally untrusted. In the case where the computer is 
untrusted you can't get any guarantees. That's why most protocols assume 
that the client is at least trusted by the user of the client.


So, to sum up it seems it won't be possible to do what I need: a server
asking to sign 10 documents and being sure only those are signed.

I understand this is Anders (& CO) argument about "smartcards were not
designed for Web"


In the other hand, do you think is possible to "extend" WebcryptoAPI to
generate/use keys to/from browser or system keystore?
IMHO, how it actually works, sucks.


Regards (and thanks)

PS: Never trust the client...that also sucks.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Can sign but cannot encrypt email using a valid S/MIME certificate

[Robert Relyea]

On 09/04/2015 05:06 AM, Thibault Derrien wrote:


Dear all,

I have obtained numerical certificates of national certification
authority in Czech Republic (ICA).

1/ I have imported the certificate into Mozilla Thunderbird > Account
Settings > Security > Digital Signing.
- It shows Software Security Device:TwinsQS 10/07/2015.
- Digitally sign messages (by default) is ticked.

In Certificates > View Certificates, I obtain "Your certificates". I
click on my certificate, and read:
"General > This certificate has been verified for the following uses:
SSL client certificate,
SSL server certificate,
Email Signer certificate,
Object Signer. "
Your cert doesn't have 'Email Recipient Certificate'. That means your 
certificate probably doesn't have Key Encipherment (see 
Details->Extensions->Certificate Key Usage).


However, Mozilla Thunderbird > Account Settings > Security > Encryption
is greyed.
Clicking on "Select..." leads to error message
"Certificate Manager can't locate a valid certificate that other people
can use to send you encrypted email messages."
There are two types of certificates used for email. One for signing and 
one for encryption. it's possible that a single email can be used for 
both. Your cert apparently only has signing. You will need a separate 
cert for encryption. (or get a new cert with both). Your encryption cert 
should have the same subject as your signing cert (ideally).


2/ If I send a new email to a coworker also working with Thunderbird on
Linux, (or another on Outlook on Windows), he obtains :
Email is signed. Signature is valid.
When your friend reads the signed email, that loads the email cert along 
with our smime configuration into his database, at least in thunderbird. 
In your case, there isn't an encryption cert included.


However, my computational center want to send me a password by using my
certificate to encrypt their email. Problem is that they don't have the
file for this. Which file should I send them ?
Send them a Signed message, that will give them your certificate (again, 
assuming you have an encryption capable cert).

Which file format should
I send ? I have too many formats existing. DER, CER, PFX, P7C, PK7, 
CRT...

- Why Thunderbird cannot import my certificate to encrypt emails ? That
would solve my issue.
- Why is there no option to attach my key into Thunderbird ? It is
present in OpenPGP but I would like to use S/MIME without this OpenPGP.

Thanks a lot for your help!

Best regards,
Thibault







  
--

Upozorneni: Neni-li v teto zprave vyslovne uvedeno jinak, neni tato e-mailova 
zprava navrhem na uzavreni smlouvy ani prijetim pripadneho navrhu na uzavreni 
smlouvy a nezaklada predsmluvni odpovednost FZU AV CR, v. v. i.
Disclaimer: If not expressly stated otherwise, this e-mail message cannot be 
considered as a proposal to conclude a contract, neither the acceptance of a 
proposal to conclude a contract, nor does it create any pre-contractual 
liability on the part of FZU AV CR, v. v. i.






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: pk12util: Wrong certificate names in database

[Robert Relyea]

On 07/27/2015 12:54 AM, Trick, Daniel wrote:

Thank you a lot for clarification, Kaspar!

So, by design of NSS, all certificates with the same DN will end up 
with the same nickname. And the very first certificate with a specific 
DN will set the nickname for all other certificates (with that same DN).


Now, I see that this works as long as we have one certificate for 
encryption, one for signing and one for auth. The application (e.g. 
Thunderbird) still picks the correct certificate, probably by looking 
at the key usage flags, although they all have the same name.


But how am I supposed to deal with the situation that the users gets a 
"new" certificate for the same DN? If there are several certificates 
for, e.g., encryption, all with the same DN - and thus also with the 
same nickname - how do we distinguish?


NSS returns the newest cert valid cert for the given operation.



(I'm asking this, because I also need to be prepared for the case that 
user certificates are "refreshed" when they expire - or shortly before 
they expire. So, for a limited amount of time, we may need to keep the 
"old" /and/ the "new" certificate in the store)


Yes, that's pretty common, including in Thunderbird (where you have a 
lot of old encryption certs).


There are not so good, and not uncommon corner cases to watch out for: 
If you have 2 certs with the same DN, but different rolls where both are 
active at the same time, you can't use nicknames to select the cert. If 
you want to delete a cert, you can't use nickname to uniquely identify 
the cert you want to delete. When you need fine grain control, the 
application should use issuer/serial number to identify the cert (I 
think all the mozilla apps have gone to this now).


bob


Regards,
Daniel


Am 26.07.2015 um 08:38 schrieb Kaspar Brand:

On 20.07.2015 14:05, Trick, Daniel wrote:

I'm facing a new problem regarding pk12util from NSS Tools:

When I import the _first_ certificate of a user into the database with
pk12util, then certificate's name in the NSS database will be:
*NSS Certificate DB: 
*
Okay,  but as soon as I import the _second_ certificate (or any further
certificate), it won't be added to the DB with a distinct name. 
Instead,

the entry that was created when importing the _first_ certificate will
appear several times! :-\

[...]

*Is this an intended behaviour of pk12util, and if so, how can I 
achieve
the required result? If it's *not* intended and actually a bug, 
should I

file a bug report now?*
*

Yes, it is by design. All certificates with the same subject DN are
expected to share a common nickname, otherwise you would end up with a
corrupt DB, see e.g. 
https://bugzilla.mozilla.org/show_bug.cgi?id=594297.


Kaspar





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: placing NSS in fips mode using modutil is "forgotten" ?

[Robert Relyea]

On 06/10/2015 06:15 AM, Paul Wouters wrote:


Hi,

I'm trying to do various FIPS tests for libreswan. Our testing system
using KVM is a little tricky to selectively boot with fips=1, so I
did some scripting to get everything into faked FIPS mode.

It basically comes down to first running a script that:

- creates /etc/system-fips
- disable selinux (for next step)
- fake /proc/sys/crypto/fips_enabled by
  echo "1" > /tmp/fips_enabled
  mount --bind /tmp/fips_enabled /proc/sys/crypto/fips_enabled
- running modutil:
  /usr/bin/modutil -dbdir /etc/ipsec.d -fips true -force
  /usr/bin/modutil -dbdir /etc/ipsec.d -chkfips true
  (which DOES output: (FIPS mode enabled.")
- starting libreswan via systemctl start ipsec.service

libreswan, which has its own checks for /proc/sys/crypto/fips_enabled
and /etc/system-fips confirms it is in FIPS mode.

But somehow, the NSS library is still not in FIPS mode. I suspect the
dance through systemd might cause this? Do some environment variables
get set and lost? Is there a way to export some environment variables
to force NSS harder?
The most likely cause is nss wasn't opened using /etc/ipsec.d as it's 
database. If this is a library, this could be caused by the application 
opening it's own database first, which means the default slot will be 
whatever the application openned. If you check the slot for your 
database, it should still be a FIPS slot.


bob


Paul





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS set extractable = no

[Robert Relyea]

On 05/18/2015 03:04 PM, Arthur Ramsey wrote:
I have a requirement to disable key export on a key stored in a NSS DB 
in FIPS mode.  I read through the documentation and found mention of 
the ability to do this, but not how.  Where can I find information on 
how to disable key export?  I will be using the NSS module via Java to 
obtain FIPS 140-2 compliance.  I imported the key via p12 format, but 
I could complete the entire process via NSS if needed.


We only support sensitive, not extractable in the NSS FIPS.

If you are talking about database keys, the actual key is stored p12 
encrypted in a database, so there would be no way to prevent someone how 
has both the database and the password for the database from extracting 
the key.


That being said several versions of NSS already has FIPS 140-2. I 
believe FIPS 140-2 allows extracting keys with wrapping keys.


bob


Thanks,
Arthur






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PK11SymKey in FIPS mode from nothing

[Robert Relyea]

On 05/12/2015 10:44 AM, Paul Wouters wrote:

On Tue, 12 May 2015, Robert Relyea wrote:

 So, in FIPS mode, in a standalone test program, what is the correct 
way to

 turn g^ir into PK11SymKey.



  PK11SymKey *sym_key = PK11_ImportSymKey(slot,
CKM_DH_PKCS_DERIVE,
PK11_OriginUnwrap,
  CKA_ENCRYPT, 
&key_item,

 NULL);

 which is of course not valid in FIPS mode.


This should be fine for CAVs testing, as long as it is running the 
same code as it would run if it's in FIPS mode (which it will).


I'm not sure you understood. We have two problems.

If we want to run CAVS testing on building packages, and the builder
machine runs in FIPS, we have a problem.

We would like to run these CAVS tests on daemon startup, even in FIPS
mode.
So you are talking about FIPS Power on self tests/ Known answer tests? 
You can do that as follows:


1) derive your test known answer key.
2) use the known answer key to encrypt a some known data.
3) compare the encrypted data with the known encrypted answer.

You can't access the generated key in FIPS mode because that violates 
the softoken FIPS boundary.


For your actual CAVS testing, you actually need the real key data. In 
that case you have to work within the FIPS boundary.
(Of course this all goes away when we push the IKE derive function into 
softoken itself and have softoken run the CAVS and POST, freeing 
libreswan from needing a separate validation.


bob


Paul





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PK11SymKey in FIPS mode from nothing

[Robert Relyea]

On 05/12/2015 08:58 AM, Andrew Cagney wrote:

Hi,

I'm looking to clean up some test code (IKEv2, NISTs CAVP tests), so that
they "work" in FIPS mode (what ever that means).
So CAVS tests require hooking outside  the FIPS mode boundary because 
CAVS tests access CSPs which aren't allowed outside the boundary in 
FIPS. When we run NSS CAVS, we run them through private interfaces that 
aren't available when the module is up and running in FIPS mode.


The test inputs look like:

Ni = 3651fef5c9c35e93
Nr = c09a8b90a3f04d59
g^ir =
d084a30166a50fb7325c3960874a839449ef9741c2f4f947d0201dd8c1269273d79509f37e3ca3eb4fa2fe2a28254e289cd3f34dad4eb4df1a07685a4b8a94fa61e2491f7598b3ce65547ff133b3f63d1ac4175eaa695033f3cedb026a6873a36455172a8540b8a5d23a0143bed0390ee49b168269d75fffee9fb62be965993c
g^ir (new) =
52f00ab174c25d5b7139ae5ff4e8e9eddee5992d2e36adf8a559ffd90dab1442e4fbe429d320c0f33552a17d1557fa41ea70e8fb916c4fa27ed52b5f8ebd8461afa78f1159159a64055ac5f6319e29c28eae58cbc6847770f32c3fed1d04750484f854790f95e9ec01bc5bc461f24966462e359511329305038e94deb6dd42c2
SPIi = 8e5c3ae507221684
SPIr = b1f201bb155c3acd

The problem is with g^ir.(which is the DH exponentiation).  The
calculations rely on g^ir being in a PK11SymKey.

In the "real world" (as in the non-test code),  "i" is created as a
PK11SymKey, and hence a g^ir PK11SymKey can be derived from that.  Here,
though, I've no secure starting point - I'm just given the raw byte value
of g^ir.

So, in FIPS mode, in a standalone test program, what is the correct way to
turn g^ir into PK11SymKey.

Andrew

PS: The current code uses the hack (something like) from the NSS examples:

 PK11SymKey *sym_key = PK11_ImportSymKey(slot,
CKM_DH_PKCS_DERIVE,
 PK11_OriginUnwrap,
 CKA_ENCRYPT, &key_item,
NULL);

which is of course not valid in FIPS mode.


This should be fine for CAVs testing, as long as it is running the same 
code as it would run if it's in FIPS mode (which it will).


bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: target parameter to PK11_Derive

[Robert Relyea]

On 05/07/2015 11:49 AM, Andrew Cagney wrote:

[inline]

On 5 May 2015 at 13:18, Robert Relyea  wrote:

The target Mechanism is the operation you are going to use the target key

for, It shouldn't match the mechanism used to derive the key. It is
basically used to set the appropriate key type and flags on the resultant
key. Example psuedo code:

key1 = derive(keybase, mech=CKM_XOR_BASE_AND_DATA,
target=CKM_SHA1_KEY_DERIVATION, data);
key2 = derive(key1, mech=CKM_SHA1_KEY_DERIVATION, target=CKM_AES_CBC,
NULL);
decrypt(key2, mech=CKM_AES_CBC, input, output);

  Ideally you should try to keep it consistent with how your are planning
on using the key, but in practice as long as the key is basically the same
kind of key, the extact value of target is not necessary (You can use a key
generated with target CKM_AES_CBC on an CKM_AES_ECB operation, for
instance). Target may also be used to try to set the appropriate key length
(if key length isn't supplied).



Thanks for the clarification; my reading of the documentation wasn't too
far off.

For the intermediate values I think I'll try something like
CKM_VENDOR_DEFINED; and, to your point, ensure all the final keys have
meaningful values.
I'm not sure CKM_VENDOR_DEFINED will be the right thing. The 
intermediate values are likely CKK_SECRET_KEYS with CKA_DERIVE set to 
true, It's probably best if you want to use the same value to use 
something like CKM_XOR_BASE_AND_DATA or something similiar.


bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: target parameter to PK11_Derive

[Robert Relyea]

On 05/05/2015 08:42 AM, Andrew Cagney wrote:

Hi,

I'm cleaning up some code (it has a long history) that, among other things,
computes IKE's PRF (hmac) and PRF+ (key derivation function).  The
computation involves the use of PK11_Derive to perform lots of
concatenation, padding, xoring, and hashing(1).  To get an idea, the PRF+
function (which uses PRF, which uses HASH) is described in the RFC as:

prf+ (K,S) = T1 | T2 | T3 | T4 | ...

where:

T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)

For specifics: PRF http://tools.ietf.org/html/rfc2104 PRF+
http://tools.ietf.org/html/rfc7296#page-48

The code works - at least in the sense that it computes the same values as
the test vectors found on http://csrc.nist.gov/groups/STM/cavp/index.html

The thing I'm not sure about is how the code is using PK11_Derive "target"
parameter for its intermediate(2) operations.

For instance, when doing concatenation and xoring, the "derive" parameter
might have sane with values like:

   CKM_CONCATENATE_DATA_AND_BASE
   CKM_CONCATENATE_BASE_AND_DATA
   CKM_CONCATENATE_BASE_AND_KEY
   CKM_XOR_BASE_AND_DATA

while the *target* parameter gets values like:

   CKM_EXTRACT_KEY_FROM_KEY
   CKM_ SHA1_KEY_DERIVATION (when BASE_AND_KEY)
   CKM_CONCATENATE_BASE_AND_DATA

Similarly, when performing the hash using PK11_Derive, the "derive"
parameter is something sane like:

   CKM_SHA1_KEY_DERIVATION

yet the *target* parameter is:

   CKM_CONCATENATE_BASE_AND_KEY

Does any of this matter?  Is there a preferred value?  (If there is I could
simplify some code further).  And are there any, mumble mumble, security,
mumble, mumble, implications?


The target Mechanism is the operation you are going to use the target 
key for, It shouldn't match the mechanism used to derive the key. It is 
basically used to set the appropriate key type and flags on the 
resultant key. Example psuedo code:


key1 = derive(keybase, mech=CKM_XOR_BASE_AND_DATA, 
target=CKM_SHA1_KEY_DERIVATION, data);

key2 = derive(key1, mech=CKM_SHA1_KEY_DERIVATION, target=CKM_AES_CBC, NULL);
decrypt(key2, mech=CKM_AES_CBC, input, output);

 Ideally you should try to keep it consistent with how your are 
planning on using the key, but in practice as long as the key is 
basically the same kind of key, the extact value of target is not 
necessary (You can use a key generated with target CKM_AES_CBC on an 
CKM_AES_ECB operation, for instance). Target may also be used to try to 
set the appropriate key length (if key length isn't supplied).


Most of these key derive operations either ignore keyType or take 
CKK_GENERIC_SECRET keys, so bad things aren't likely to happen if you 
mix up target a bit, but certainly the final resultant keys should 
target the proper crypto targets our your decrypt operation will fail 
with an inappropriate key type.


bob


Andrew

PS: If there's documentation I've missed, please let me know :-)

--

(1): It's computing the hash using calls like PK11_Derive
(derive=CKM_SHA1_KEY_DERIVATION) rather than the lower level hash
interface.  This is because PK11_Derive returns a PK11SymKey, hopefully
keeping the result secure.

(2): Once the keying material has been created things become more sane, for
instance when extracting (CKM_EXTRACT_KEY_FROM_KEY) an AES_GCM key the
target is CKM_AES_GCM; and when extracting IV that ends up on the wire the
target is CKM_VENDOR_DEFINED.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Problems with FF and internal certificates

[Robert Relyea]

On 05/04/2015 10:09 AM, Brian Smith wrote:

On Fri, May 1, 2015 at 9:11 AM, Tanvi Vyas  wrote:


On Apr 27, 2015, at 2:03 PM, Michael Peterson <

michaelpeterson...@gmail.com> wrote:

Now, in the album I posted above (https://imgur.com/a/dmMdG), the last

two screenshots show a packet capture from Wireshark. It appears that
Firefox does not support SHA512, which is kind of supported by this article
(
http://blogs.technet.com/b/silvana/archive/2014/03/14/schannel-errors-on-scom-agent.aspx).
I'm not exactly sure this is true, and it seems like a silly thing for
Firefox to drop support though (this previously worked), especially if
every other browser in the world supports this.


I think this was an NSS bug where we didn't include the SHA512 hash in 
the advertized list of supported hashes. It wasn't dropped support. In 
previous versions of TLS you didn't advertise which hashes you 
supported, so things signed with SHA512 just worked.  Now you need to 
advertise it, and NSS was just missing the hash (it's fixed in the 
latest version of NSS).



So there's everything we've found, and some of my assumptions. Does

anyone know what is actually going on with Firefox. Is this a bug? Are we
doing something wrong? How do we fix this?


SHA-384 is SHA-512 truncated to 384 bits.


Not exactly. SHA-384 is mechanically the same algorithm as SHA-512, with 
a truncation, but it's not the same bits. SHA-384 has a unique set of 
initializers so if you do a SHA-512 and truncate it to 384 bits and the 
do a SHA-384  on the same data, you have the same security and 
performance characteristics, but not the same bits.


 (I think Brian knows this, and that his point is from a security point 
of view, they are exactly identical, both in performance and in the 
actual security of the hash. For the uninitiated, though, the actual 
bits on the wire are different).




I guess your ECDSA certificate is using the P-384 curve. If so, your
SHA-512 digest is truncated to ~384 bits in order to work with the P-384
curve. (If you are using the P-256 curve, then it is truncated to ~256
bits.)

Consequently, there's no advantage to using SHA-512 instead of SHA-384.


Other than compatibility with someone that chose to sign using SHA-512.

bob


Cheers,
Brian





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS support for RFC7512 PKCS#11 URIs

[Robert Relyea]

On 05/03/2015 02:17 AM, David Woodhouse wrote:

On Sat, 2015-05-02 at 18:33 -0700, Jan Pechanec wrote:

On Fri, 1 May 2015, David Woodhouse wrote:


On Fri, 2015-05-01 at 11:35 +0100, Alan Braggins wrote:

On 30/04/15 17:56, David Woodhouse wrote:

Has anyone looked at implementing RFC7512 support, allowing an object
to be specified by a PKCS#11 URI?

I don't suppose you know why RFC 7512 uses CKA_ID but not CKA_SUBJECT,
when PKCS#11 says " The*CKA_ID*attribute is intended as a means of
distinguishing multiple public-key/private-key pairs held by the same
subject"
and "it is possible that keys for different subjects may have the
same*CKA_ID*value without introducing any ambiguity"?

That question would be better directed to the authors of the RFC. I've
added Jan to Cc.

Yes, in isolation both CKA_SUBJECT and CKA_ID are ambiguous since
multiple certificates can exist with the same subject, and multiple
certificate can exist with the same private key (hence the same
CKA_ID).

I'm not quite sure of the motivation for omitting CKA_SUBJECT from the
URI specification. Perhaps because it's redundant to a *certain*
extent with CKA_LABEL — in the relatively rare case that CKA_ID isn't
actually unique, hopefully CKA_LABEL is sufficient to disambiguate.

Hi David, that's a very good question.  It was a deliberate decision
back in the days of filing the first I-D in March 2010.

I didn't want to delve into a certificate.  I know there is a key ID
in X.509 v3 which is expected to be in CK_ID if present in the cert,
but I didn't want to go beyong an id.  Any other component path
attributes are directly PKCS #11 related.

I thought about adding CK_SUBJECT there while writing 00 based on what
we were doing with Darren (cc'ed) in Solaris those days.  But then,
CKA_START_DATE and CKA_END_DATE could be useful as well, to pick valid
certificates, for example, and also CKA_SERIAL_NUMBER and CKA_ISSUER,
and even CKA_HASH_OF_SUBJECT_PUBLIC_KEY.  Possibly something else.

The scheme definition would grow significantly and in general we were
concerned that the more complex the scheme would become to be, the
more difficult would be to use it.  Using the "object" attribute
seemed like the best way to identify a key, with an ID if needed, and
possibly library attributes.  Also note that comparing URIs would
become more difficult as the subject attribute would need to be
normalized (how exactly?).

So, we started with a basic list of attributes we thought were enough
to identify an object or token and expected people to tell us what
else was useful for them.  That's how we added library-* and slot-*
attributes (after a long discussion a few years ago, we deliberately
decided not to use a slot since its ID is not stable across PKCS #11
module initialization, but then again, someone asked for it and we
thought that it was just better to add it), and we also added query
component attributes, including the PIN in the URI, which we also
initially opposed to have but were convinced to add by early adopters.

And in those more than 5 years since the draft 00, no one asked for
the CKA_SUBJECT attribute.

Having said that, I assumed that other URI attributes might be needed
in the future, possibly with new versions of the PKCS #11 standard; I
didn't see anything new in upcoming 2.40 useful to be added to the URI
though.  So, if there is a strong feeling about a new attribute, there
is always a way of patching the parser and filing an I-D to extend the
scheme, and let the community decide.

In this situation though, I still believe that it's better not to put
the certificate subject in there, due to the reasons mentioned above.

Regards, Jan.

Hi Jan,

Thanks for the prompt response (as ever), which I've cited in its
entirety since I'm not sure it made it to the list.

For the case of NSS, I suspect the lack of CKA_SUBJECT shouldn't be a
real problem. I've just started looking at NSS with a view to fixing
it to take PKCS#11 URIs, and it looks like the common way of
specifying a certificate is by its "nickname", which is CKA_LABEL,
using the PK11_FindCertFromNickname() function.


So in NSS, CKA_LABEL is simply a short cut to CKA_SUBJECT. That is NSS 
looks up a cert from the nickname and picks all the certs that match 
that cert's subject. The idea (back 2 decades ago when this was 
implemented) was that nickname was the user facing name for the cert 
'identity'. Multiple certs made up that identity (auth certs, 
non-repudiation certs, key exchange/encryption certs, expired versions 
of the above). As a result CKA_LABEL is not unique to a cert (anymore 
than a subject is). LABEL is not required as well (certain intermediate 
CA's may not have a label associated with them).


Currently the only unique way to identify a cert is CKA_ISSUER and 
CKA_SERIAL_NUMBER unless you want to include the value. The PKCS #11 
working group is active again at OAISIS. If we want a unique object 
identifier


I think we just need to either extend PK11_FindCertFr

Re: Key zeroization in NSS DB

[Robert Relyea]

On 03/25/2015 04:30 AM, Jan Otte wrote:

Hi,

When finding out how to do key zeroization in NSS DB I stumbled upon

https://bugzilla.mozilla.org/show_bug.cgi?id=347450

The last comment states that key zeroization is not needed for FIPS,
which is in contrast with the initial description.

What is the reason behind this - why is the key zeroization in NSS DB
not needed?


This isn't about zeroization of the database, it's about zeroing the 
internal databuffers from the database. Those buffers don't need to be 
zeroized because the data in them is encrypted. Keys in your nss 
database are stored encrypted, which is why you need to supply a 
password before you use it. If you don't have to supply a password, then 
the keys are still encrypted, but they key they are encrypted in can be 
trivially calculated given an NSS database (the password is set to the 
NULL string).


As for zeroization of the database itself, it depends on why you want to 
do it. If you are trying to meet a particular security policy are just 
paranoid, you can set the password to an arbitrarily random string that 
you don't save (like the output of 128 bytes of /dev/random converted to 
hex). Setting the password reencrypts each entry in the database with 
that password. At this point you can simply do a database reset. (which 
basically deletes the old database and creates a new empty database). If 
you just want to 'get rid of your keys' you ca simply do a database 
reset, though in that case it's possible that data blocks in your 
database are still floating around on your harddisk free list.


It should be obvious that both of these methods would get rid of all 
your private and secret keys. What may not be obvious is the secret keys 
used to encrypt your website passwords will also be gone... Even if you 
didn't have an NSS password set initially (those passwords are also 
always encrypted and if you loose or change your NSS key database you 
will loose those passwords as well).


Also it may not be obvious that this only affects the key database, not 
the cert database. The cert database stores cryptographicly public 
information (that is information that can be sent publicly without 
breaking cryptographic security). For example, your personal email and 
client auth certificates are stored in the cert database. You can't use 
them for signing, authentication, or email decryption however, without 
the associated private keys, so the certs will still be accessible, but 
they won't be usable as user certs (they won't show up in the user cert 
side of the firefox cert view, for example).


bob


Thanks & best regards,
Jan





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Using JSS SSLSocket and and SSLServerSocket TLS 1.1 and 1.2

[Robert Relyea]

On 01/13/2015 09:18 AM, Christina Fu wrote:
jss-4.2.6-35 can be found on koji for various supported fedora 
platforms.  For rhel it's the same version number.


Christina

Are there any outside available builds, like windows?

bob


On 01/13/2015 09:09 AM, Robert Relyea wrote:

Christina, which version of JSS has TLS 1.1 and 1.2 support enabled?

Bob

On 01/12/2015 02:10 PM, deepr...@gmail.com wrote:

Folks,

Sorry for the totally newbie question but I've hunted high and low.

I am supporting some Java code that uses JSS4, NSS to provide
SSL Server side services.

In response to Poodle I've been looking this code and was able to 
Enable TLS explicitly and disable SSL to mitigate that in it's most 
basic form.


However I was hoping to be able to add at least TLS 1.1 if not 1.2 
support.


I cannot find how this is done or if possible.

I've build the latest NSS code base which seemingly supports these 
protocols, and build JSS around it but can't seem to get a TLS 
1.1/1.2 connection.


The JSS source code also doesn't show any of the SHA256 ciphers etc 
that imply TLS 1.2..so I've come the conclusion that I cannot use 
JSS to execute TLS 1.1/1.2 server side connections.


Hopefully I'm wrong, or stupid but not both.

Can anyone confirm, deny or otherwise point me in the right 
direction on this topic.


Thank you

Colin










smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Using JSS SSLSocket and and SSLServerSocket TLS 1.1 and 1.2

[Robert Relyea]

Christina, which version of JSS has TLS 1.1 and 1.2 support enabled?

Bob

On 01/12/2015 02:10 PM, deepr...@gmail.com wrote:

Folks,

Sorry for the totally newbie question but I've hunted high and low.

I am supporting some Java code that uses JSS4, NSS to provide
SSL Server side services.

In response to Poodle I've been looking this code and was able to Enable TLS 
explicitly and disable SSL to mitigate that in it's most basic form.

However I was hoping to be able to add at least TLS 1.1 if not 1.2 support.

I cannot find how this is done or if possible.

I've build the latest NSS code base which seemingly supports these protocols, 
and build JSS around it but can't seem to get a TLS 1.1/1.2 connection.

The JSS source code also doesn't show any of the SHA256 ciphers etc that imply 
TLS 1.2..so I've come the conclusion that I cannot use JSS to execute TLS 
1.1/1.2 server side connections.

Hopefully I'm wrong, or stupid but not both.

Can anyone confirm, deny or otherwise point me in the right direction on this 
topic.

Thank you

Colin





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Accessing Firefox keystore

[Robert Relyea]

On 01/09/2015 08:03 AM, Opa114 wrote:

i do. but i want to parse the cert8.db or maybe access this fle in an easier 
way with JAVA. i have to read the file and maybe i have to remove and/or add 
new certificate to it.
While there is some documentation on the format of cert8.db, If you are 
accessing it from Java inside firefox and you aren't accessing it from 
JSS, then you run the risk of corrupting the database.


If you are just accessing it standalone, then you may have more success, 
though that's a pretty complicated route. The file is in the old 
berkeley DB format, which means you'll need to access it some how. I 
doubt there are java bindings for that code, berkeley stopped 
maintaining it before Java existed (it eventually became sleepycat). So 
first you'd need the old DB format.


They way NSS uses the database records is documented here: 
http://www-archive.mozilla.org/projects/security/pki/nss/db_formats.html
Even though this says cert7.db, it's basically the same, except cert 8 
databases may contain crls (iirc).


This doesn't get you signing access. For that you'd need to also access 
key3.db, which has it's own set of 'row'/'payload' values, as well as 
PKCS5 encoded keys.


bob



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Accessing Firefox keystore

[Robert Relyea]

On 12/11/2014 12:33 AM, helpcrypto helpcrypto wrote:

Hi again, sorry for delay.

Yes, you can (SHOULD) use SunPKCS#11 to access directly the
libraries/modules.
You can do it two ways:

  - attack libraries directly
  - parse (legacy) secmod.db on Firefox profile to list modules/libraries.
Actually this is a very good way to corrupt your database. Mozilla still 
uses the old database, so accessing you NSS database from SunPKCS#11 
with another softoken module while you are running will corrupt your 
database.


Unfortunately the only safe way is to use JSS, as sucky as it is. You 
can use JSS as just a provider and use your normal Java interfaces, 
however. You don't need to use the direct to NSS bindings.


bob


Have a look on

http://stackoverflow.com/questions/2873581/is-it-possible-to-access-a-bdb-from-pure-java
 sethi.org/tmp/ssh/src/com/mindbright/bdb/DBHash.java

It's quite complex, so if you get lost, I could try to send you some code.

Regards.




On Mon, Dec 8, 2014 at 7:48 PM,  wrote:


I have the same question / problem.

I want to access the mozilla keystore (firefox and thundebird) via Java
(No Java Applet) or C#? I found the JSS/NSS Provider, but no information on
how to use it and on which way i can access the keystores. So how is it
possible? Little example Code would be helpful. And is it possible with C#?

Or there are other ways to access them? maybe read in the whole cert8.db
file, but it looks like that the file is encrypted. so the question is, how
could i decrpyt the file?

Hope someone could help :)
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: libnsssysinit

[Robert Relyea]

On 12/08/2014 08:59 AM, David Woodhouse wrote:
I still maintain that the path to sanity involves killing 
/etc/pki/nssdb entirely, and then you can look at applying *correct* 
fixes to whatever's still not behaving correctly.


The whole point of /etc/pki/nssdb is so you have one place to install 
stuff. It's the default for anything that I've had a say in and will 
continue to be the default.


bob






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: libnsssysinit

[Robert Relyea]

On 12/08/2014 05:05 AM, David Woodhouse wrote:

On Mon, 2014-12-08 at 10:15 +, Martinsson Patrik wrote:

So, to summarize,
$> sudo update-alternatives --install /usr/lib64/libnssckbi.so
libnssckbi.so.x86_64 /usr/lib64/p11-kit-proxy.so 1000

$> cat /etc/pki/nssdb/pkcs11.txt
library=/usr/lib64/p11-kit-proxy.so
name=p11-kit-proxy
NSS=trustOrder=100

You shouldn't need that bit. It was only pam_pkcs11 which wasn't loading
the smartcard modules via the nssdb, and it wants to load OpenSC
*explicitly* anyway. And besides, *nothing* should be
using /etc/pki/nssdb since we can ditch the Shared System Database
nonsense. Just let use pam_pkcs11 use its default /etc/pam_pkcs11/nssdb
instead.


Nothing in the above paragraph is true.

openning
1)sql:/etc/pki/nssdb is *STILL* the recommended action for applications 
(whether or not nssysinit is installed), and
2) what ever the recommendation, pam_pkcs11 still used /etc/pki/nssdb 
(by default, always), not /etc/pams_pkcs11/nssdb. (It never has used).





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: libnsssysinit

[Robert Relyea]

On 12/04/2014 02:00 PM, David Woodhouse wrote:

On Thu, 2014-12-04 at 10:33 -0800, Robert Relyea wrote:

That one. libnssckbi.so is what provides the default trust roots. It's
*always* supposed to be loaded in an NSS system. You shouldn't need to
add it manually. I don't.

Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the
application or by someone explicitly loading it into the
pkcs11.txt/secmod.db. It is not loaded automatically by every nss
application.

OK... but applications such as firefox which actually want trust to work
should be loading it, right?
firefox loads libnssckbi.so only if not other 'Root Certs Module' has 
been loaded. the pk11-kit module is a Root Certs Module, so if it's been 
loaded, then libnssckbi.so isn't.


Yes, there are some applications which use NSS only for private crypto
purposes and don't need the trust roots, but Patrik seemed to be
suggesting that in RHEL, even Firefox wasn't loading libnssckbi.so until
he manually added it to pkcs11.txt/secmod.db.


I believe the p11-kit does some magic to get it loaded for mozilla and
the root store. Kai worked with stef to get that working, kai do you
recall how that hooks in?

I thought we really were just replacing libnssckbi.so with our own.
Which is fine as long as it's actually being loaded.
Sort of, It's not the same name, it's a different module, but it has the 
same attributes.


bob







smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: libnsssysinit

[Robert Relyea]

On 12/04/2014 03:31 AM, David Woodhouse wrote:




You say that this shouldn't be necessary (and probably a bug), just to
clarify things for me, do you mean that,

1 ) "adding the libnssckbi.so to shouldn't be necessary since it should
already be there from the beginning, and that the bug is that the
library is missing from the default setup", or

That one. libnssckbi.so is what provides the default trust roots. It's
*always* supposed to be loaded in an NSS system. You shouldn't need to
add it manually. I don't.
Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the 
application or by someone explicitly loading it into the 
pkcs11.txt/secmod.db. It is not loaded automatically by every nss 
application.


I believe the p11-kit does some magic to get it loaded for mozilla and 
the root store. Kai worked with stef to get that working, kai do you 
recall how that hooks in?


bob


(Note that you also shouldn't need to add your CAs to the actual sqlite
database in /etc/pki/nssdb either, since they should be coming from your
"libnssckbi.so" which is actually p11-kit.)



Now the libp11-proxy,


I worked around it by symlinking /usr/lib64/libnssckbi.so to
p11-kit-proxy.so instead of p11-kit-trust.so, which gives me the trust
roots *and* the other loaded modules. That one probably ought to be
the default.

Ok, I did the same thing. Using the alternatives system.


Firefox only asks me to log into my p11-kit-provided hardware tokens

when I go to a web site which wants a certificate, which is fair
enough.

Yes, same behavior here, I was mistaken when I stated that it actually
asked for pins to GNOME keyring and the Secret Store.
Firefox behaves in my opinion as expected, and I don't need to "manually
mess" with the users nssdb - the default will just work as I expect
(trusting my CA and ask for PIN to hardware token when requested).

Did you have to manually add libnssckbi to Firefox too? Remember, that
uses its own database and not sql:/etc/pki/nssdb.


Evolution does ask for a PIN for GNOME keyring and the Secret Store.
Stef suggests that's because Evolution doesn't handle
CKF_PROTECTED_AUTHENTICATION_PATH. I filed this bug for that:
https://bugzilla.gnome.org/show_bug.cgi?id=741059

Cool, then we have the same behavior and a possible reason for why it
behaves like it does. The same thing goes for chrome, I'll file a
bug-report to those ppl referring to this bug.

Chrome uses sql:$HOME/.pki/nssdb and not sql:/etc/pki/nssdb. Did you add
libnssckbi.so to *that* one?

(Evolution will use sql:/etc/pki/nssdb *if* it's enabled, and
sql:$HOME/.pki/nssdb if not. A piece of horridness fundamental to the
"design" of the NSS Shared System Database.)


breaks pam_pkcs11. Using the above config, pkcs11_inspect throws the
following,
...
DEBUG:pkcs11_lib.c:272: loading Module explictly,
moduleSpec= module=/usr/lib64/pkcs11/opensc-pkcs11.so
DEBUG:pkcs11_lib.c:276: Failed to load SmartCard software (null)
ERROR:pkcs11_inspect.c:73:
load_pkcs11_module(/usr/lib64/pkcs11/opensc-pkcs11.so) failed:
Not really sure why this happens, but changing the lines,

I suspect this is because it's trying to explicitly load
opensc-pkcs11.so when it was *already* loaded. I wonder if works better
if you point it at p11-kit-proxy.so instead. Not sure if that can cope
better with multiple initialisations, if such a thing is even possible.

Further discussion of that might be more appropriately targeted to the
OpenSC mailing list, since pam_pkcs11 is theirs too.

In the meantime, given the bug that libnssckbi.so doesn't seem to show
up for you unless explicitly requested, a potential workaround might be
to point pam_pksc11 at a NSS DB which *doesn't* request it (it can
request p11-kit-trust.so instead).







smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: libnsssysinit

[Robert Relyea]

To level set everyone, here, Martinsson is clearly running on RHEL, so 
most of his questions and my answers where are RHEL specific.


On 11/19/2014 12:17 PM, Martinsson Patrik wrote:

Hi everyone,

I Need some help understanding the usage of the libnsssysinit-library
(or a recommended method in handling the scenario described below).

First I'll write shortly about our scenario,
- We manage around 150 Red Hat Clients (atm v6.6 but in the progress of
updating to 7.0)
- We use "smartcard-login" for all clients
- We have a custom CA that issues our certificates (both to our cards,
but also to our "internal services" like mail/etc.).

Issues to solve,
- Have all kinds of applications trust our CA.
- Have all kinds of make us of our pkcs11-module if requested.

It's sounds so simple, but it turns out to be a real hassle.

What we got so far,
- Make puppet distribute our root-ca-certificate to
'/etc/pki/ca-trust/source/anchors/' and import the libnssckbi.so into
'/etc/pki/nssdb' (/usr/bin/modutil -force -dbdir /etc/pki/nssdb -add
'System CA-trust' -libfile /usr/lib64/libnssckbi.so), execute
'update-ca-trust'. This actually makes everything work as expected, this
is an really awesome way for administrators to distribute certificate's
that the client should trust by default.

Still kind of a hassle,
- Getting various applications to use the custom pkcs11-module
(google-chrome, firefox are the ones I've tried so far).
This is still the issue with nsssysinit. It currently only works if the 
the application open sql:/etc/pki/nssdb. Currently firefox doesn't even 
use the sql database.


You can force the use of sql database with the environment variable ( 
NSS_DEFAULT_DB_TYPE ), but it still doesn't force opening /etc/pki/nssdb.


  


So, what we do is that we distribute this custom module within a
rpm-package, and in the post-section of the rpm we insert it
in /etc/pki/nssdb (/usr/bin/modutil -force -dbdir /etc/pki/nssdb -add
NetiD -libfile /usr/lib/libiidp11.so). We then point pam_pkcs11
to /etc/pki/nssdb, and everything as far as pam_pkcs11 is concerned
works as expected.



  The problem is when firefox/thunderbird/google-chrome
should make use of the smart-card. Today we manually make the same
import as just mentioned into ~/.{mozilla,thunderbird}/.*default/ &
~/.pki/nssdb, but after trying to read up in this area I get the
impression that this last part shouldn't really be necessary since I
should be able to use the libnsssysinit-library instead (which in turn
would load everything that is in the global nssdb).
Unfortunately these apps do not use nsssysinit. Once you've set the sql 
environment variable, you can force them to use nssysinit putting the 
attached pkcs11.txt file in the profile directory.


You can merge the certs and keys from the old database using certutil 
--merge. Be sure to use the dbm: prefix to access the old database.



This would be great
since it would mean that everything we need to do is make sure that the
libnsssysinit.so is in the users-various-nssdbs (and as soon as we need
to make a change/update/or whatever we just do it to the global one).
But this is were I get stuck.

So some questions,

1 ) Does libnsssysinit.so even work as I think it does ?
2 ) Is it worth switching to the new nssdbformat (sql). Since it isn't
enabled by default as far as i know (atleast not on rhel7, the
'NSS_DEFAULT_DB_TYPE' is not set to  sql which makes it default to the
old format) ? It would mean that we need to export that variable
globally to every user (which isn't a problem, I'm just wondering if
that is something we *should* do, or if it's fine the way it is).

I've tried the following,

$> modutil -list -dbdir sql:/etc/pki/nssdb/

Listing of PKCS #11 Modules
---
   1. NSS Internal Crypto Services
 slots: 3 slots attached
status: loaded

 slot: NSS Internal Cryptographic Services
token: NSS Generic Crypto Services

 slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB

 slot: NSS Application Slot 0004
token: NSS system database

   2. System CA-trust
library name: libnssckbi.so
 slots: 2 slots attached
status: loaded

 slot: /etc/pki/ca-trust/source
token: System Trust

 slot: /usr/share/pki/ca-trust-source
token: Default Trust

   3. NetiD
library name: libiidp11.so
 slots: 1 slot attached
status: loaded

 slot: Alcor Micro AU9540 00 00
token: XX

The 'System CA-trust' and the 'NetiD' modules are the ones I would like
for every user to have in theirs nssdb's (after i added the
libnsssysinit.so ofc)

So, here's how my locally nssdb looks like,

$> cat /home/username/.pki/nssdb/pkcs11.txt
library=
name=NSS Internal PKCS #11 Module
parameters=configdir='sql:/home/username/.pki/nssdb'  certPrefix=''
keyPrefix='' secmod='secmod.db' flags=
updatedir='/home/

Re: Reducing NSS's allocation rate

[Robert Relyea]

On 11/11/2014 12:32 PM, Ryan Sleevi wrote:

On Tue, November 11, 2014 10:26 am, Nicholas Nethercote wrote:

  On Mon, Nov 10, 2014 at 7:06 PM, Ryan Sleevi
   wrote:

Not to be a pain and discourage someone from hacking on NSS

  My patches are in the following bugs:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1094650
  https://bugzilla.mozilla.org/show_bug.cgi?id=1095307
  https://bugzilla.mozilla.org/show_bug.cgi?id=1096741

  I'm happy to hear specific criticisms.

  Nick
  --

Not trying to be a pain, but I don't think that's fair to position like
that. I'd rather the first question be answered - each one of your patches
adds more branches and more complexity.


OK, looking at that patches, I would challege that assertion. The patch 
in  https://bugzilla.mozilla.org/show_bug.cgi?id=1094650 actually 
simplifies the code. I do agree we need to make complexity versus reward 
calculations, but most of these changes don't raise the complexity bar 
very high, if at all.

That part is indisputable, even if
it may be seen as small.

Sorry, I just disputed it;).

  However, what measures do we have to ensure that
this is meaningfully improving any objective measure of performance (other
than allocation churn, which allocators are exceptionally capable of
handling)?
I agree that these changes should be targeted based on instrumentation. 
I believe Nicholas has provided this in the bug.

  How do we ensure this doesn't regress?
I think that depends on the change.  Certainly 
https://bugzilla.mozilla.org/show_bug.cgi?id=1095307 is simple enough, 
that the combination of review and normal testing should give us 
confidence in the patch's correctness.



I'd say the same forhttps://bugzilla.mozilla.org/show_bug.cgi?id=1094650  .
The patch in bug  https://bugzilla.mozilla.org/show_bug.cgi?id=1096741  seems 
more risky, as it delays allocation. So it would require more testing and and a 
more dillegent review, and may actually cross the complexity/benefit bar for 
me. (also, the code in question is code meant to avoid cache attacks, we want 
to make sure we don't reintroduce a new back channel attack).


Otherwise, we're adding
complexity without any benefits. And I don't think there are - or at
least, I haven't seen, other than "reduces allocations".
For me the bar is pretty low, particularly since I've seen patches that 
actually simplify the code.  The 'use static until some threshold, the 
malloc' is a pretty well established meme in NSS already, and is 
particularly safe if we can see it's entire use over a single function.


The bigger issue is are we getting proper bang for the buck.  Here we 
have an NSS user who is admittedly tuning for his particular workload, 
but doing performance tuning. It's targeted by hitting the largest 
offenders using instrumented tools to figure that out given the client's 
workload, then knocking out the low hanging fruit. I think that's pretty 
classic optimization strategy.


bob


smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS modutil: Adding PKCS#11 module with PIN to nssdb

[Robert Relyea]

On 11/06/2014 04:08 PM, Mike Gerow wrote:

Thanks for the quick reply! I can see how caching the PIN would have
its issues, but I'm not interested in having NSS ask for the PIN once
and save it, but in configuring it to just use a provided PIN in the
first place.
Still has the same issue, if you configure a pin, but don't tie it to a 
token (rather than a slot), you could have that pin applied to the wrong 
device. The functionality you described above is what servers do (the 
user configures the password for a set of tokens beforehand, not 
automatic pin caching.


As I think about this more, though, I guess the solution might lie on
the PKCS#11 module side instead of in NSS, in that the token shouldn't
have its CKF_LOGIN_REQUIRED flag set (and of course be configured so
as not to require C_Login to be called before doing cryptographic
operations).
You are correct. If you don't have CKF_LOGIN_REQUIRED set, NSS won't 
prompt for the password.
That's how NSS keeps from getting password prompts when doing raw SSL 
(the internal crypto services slot is separate from the database slot 
and doesn't require a password). In FIPS mode you will get password 
prompts when doing raw SSL.


bob


But now my problem is that I have to convince opencryptoki to do
something it probably doesn't want to :-). Oh well, thanks again for
cluing me in.




No problem



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS modutil: Adding PKCS#11 module with PIN to nssdb

[Robert Relyea]

On 11/06/2014 03:12 PM, Mike Gerow wrote:

Apologies if a dupe of this shows up. I had posted my last question
without _properly_ subscribing to list and so it is stuck in some kind
of moderator queue.

I'm trying to add the opencryptoki PKCS#11 module to Chrome/Firefox's
nssdb, and it seems to have worked properly:

$ modutil -dbdir sql:$HOME/.pki/nssdb -list

Interesting that you got firefox to point to here...


Listing of PKCS #11 Modules
---
   1. NSS Internal PKCS #11 Module
slots: 2 slots attached
status: loaded

slot: NSS Internal Cryptographic Services
token: NSS Generic Crypto Services

slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB

   2. TPM
library name: /usr/lib/x86_64-linux-gnu/opencryptoki/libopencryptoki.so.0
slots: 1 slot attached
status: loaded

slot: OpenCryptoki Software Backend
token: IBM OS PKCS#11
---

The only issue is that when the application uses the module for the
first time it requests a PIN from the user. I'm actually more
interested in the privilege separation that a PKCS#11 module provides
so I have this PIN set to a simple value that I don't really consider
a secret.
Firefox doesn't cache pins for tokens anywhere. I don't think Chrome 
does either. It's a tricky thing that can easily cause problems if it 
goes wrong. If, for instance, you had a removable token and replaced 
that removable token with a different token. If the pin caching code 
isn't implemented correctly, you could hammer the token with retry 
attempts without the user every noticing, until they try to use the 
token for real.


I know some server products some pin caching so that you can use 
unattended operations, and the code records the token name so there is 
at least some attempt to prevent token smashage.


Upshot is "there probably isn't a way to do what you want, and providing 
one could be a slightly longer rope than we'd like to pass on to the users".


bob


Is it possible to add the PIN for the module to the nssdb as well so
that I can prevent the user from being asked for it?





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: When will TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite be available?

[Robert Relyea]

On 09/28/2014 03:09 PM, Eric Rescorla wrote:

Eventually, but it's not a very high priority. Is there some reason you
can't use AES-128?
Actually the issue is ths SHA384. We need to implement the new PKCS #11 
spec to TLS key derive in softoken first.


bob


-Ekr

On Mon, Sep 22, 2014 at 4:49 PM, MJBUSCH  wrote:


When will TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite be
available?

I am looking to support websites that are built with this crypto. Only IE
is supported.

Thanks
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: issues with NSS 3.12.4

[Robert Relyea]

On 09/25/2014 04:22 AM, Sunil Raj wrote:

Hi, Even I am facing the same issue. Were u able to find the problem?


Java is trying to do something that isn't allowed in FIPS mode. It's 
trying to import a key in the clear. It should instead generate the key 
inside the token rather than import it.


bob




--
View this message in context: 
http://mozilla.6506.n7.nabble.com/issues-with-NSS-3-12-4-tp308894p323597.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Adding local cryptographic algorithms to NSS library.

[Robert Relyea]

On 08/04/2014 05:43 AM, Andrey Askerko wrote:

I want to add  support of local cryptography algorithm into firefox. And I want 
to ask some questions:
1) I must modify only NSS module, or some firefox functions/definitions too?
2) Where I can find some manual, how I can add algorithm into NSS and which 
files I must modify?

regards.  Andrey.

How do you want to use the cryptographic algorithms?

NSS can accept new algorithms through a PKCS #11 module (no need to 
modify the built-in softoken) dynamically, but we have not put in any 
features to allow, say, new SSL ciphers without modifying NSS itself. 
However if you are trying to access the algorithms through the new 
webcrypto interface, it may be possible to access without modifications. 
I don't know how the webcrypto interface is implemented in PSM. The big 
question is how is the webcrypto cipher specification mapped to PKCS #11 
mechanism.


For access using CMS/Smime, you simply need to dynamically add a new 
oid, but since you are talking about firefox, I presume you aren't 
interested in CMS.


bob



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: modutil add softokn3.dll error

[Robert Relyea]

On 07/21/2014 05:48 AM, ramahmoo wrote:

Hi,

I am trying to add the newly built softtoken dll using the following command

modutil -add "Softoken" -mechanisms RSA:DSA:RC4:DES -libfile
C:\nss-3.16.1\dist\WIN954.0_OPT.OBJ\lib\softokn3.dll -dbdir c:\nssdb

But i am getting the following error

ERROR: Failed to add module "Softoken". Probable cause : "Unknown PKCS #11
error
."

No clue what is wrong


Softoken needs additional parameters to work as a PKCS #11 module. If 
you are trying to run more than one softoken, then I also suggest 
renaming your new softoken.



bob




--
View this message in context: 
http://mozilla.6506.n7.nabble.com/modutil-add-softokn3-dll-error-tp319737.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to export private key in RSA format from NSS

[Robert Relyea]

On 07/15/2014 08:05 PM, Chuck Lee wrote:


Yes, but it doesn't work because it also calls 
PK11_ExportPrivKeyInfo() to get the RSA private key info.


Now I am trying to decrypt key exported by 
PK11_ExportEncryptedPrivKeyInfo() with method 
SEC_OID_PKCS12_V2_PBE_WITH_SHA1_AND_40_BIT_RC4 directly, which seems 
to be the most simple method to decrypt.


Hmm, 1) are you sure you used that method to export the key? It's not a 
very strong algorithm, the PKCS #12 files use it to wrap the 
certificate, not the key itself. 2) If you want to decrypt, you need to 
use that method to generate a PBE key and use it to export.


bob





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SSLKEYLOGFILE always enabled

[Robert Relyea]

On 07/16/2014 07:31 AM, Jonathan Schulze-Hewett wrote:

Does having this enabled violate the FIPS 140 requirements on exposing key 
materials in the clear?


No, because the key logging fails if you are in FIPS mode (It used the 
PK11_ExtractKeyValue() to get the key, which will return an error in 
FIPS mode.


In general, it's pretty difficult for anything in the SSL layer to 
actually foil FIPS because FIPS is implemented in softoken itself.


bob


Sincerely,
Jonathan


-Original Message-
From: dev-tech-crypto 
[mailto:dev-tech-crypto-bounces+schulze-hewett=infoseccorp@lists.mozilla.org]
 On Behalf Of Ryan Sleevi
Sent: Tuesday, July 15, 2014 6:12 PM
To: mozilla's crypto code discussion list
Subject: Re: SSLKEYLOGFILE always enabled

On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote:

  Is having it in by default useful enough to outweigh the risk?

  When the Dual_EC_DRBG news stories were blowing it, it was revealed
  that you could switch to it by just changing the Windows Registry.
  It's a Windows-supported backdoor - no malicious code needs to stay
  running on your system - just flip that bit, and delete yourself.
  After that, you're all set.

  Similarly, having this feature provided by default seems like it
  provides a very easy, supported way to extract sensitive key data to
  the filesystem or some other covert channel - without invalidating
  package signatures, hashes of libraries or binaries, etc.

  Don't get me wrong, it's invaluable to be able to use it for
  debugging, but I question to need to have it enabled by default...

  -tom

Either you control your machine, or you do not. Either the OS provides
robust controls, or it does not.

If an attacker has physical access to your machine and can set this, or if
an attacker can control your operating environment such that the
environment variable is set, it's all over. This is no different than
malware hijacking your browser of choice and hooking the API calls - which
we do see for both Firefox and Chrome.

Now, we can talk about grades of attacks, and finer nuances, but for a
debug bit that has to be set client side, it really seems a no-op, and for
which common sense would suggest is not a reasonable threat model.






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS Custom Crypto Module

[Robert Relyea]

On 07/10/2014 01:53 PM, ramahmoo wrote:

Thanks,i would ready the documentation.

Can i extend/modify the NSS internal pkcs#11 source (softokn3.dll source) to
achieve my requirement?
It's probably not a good idea to try to create your own softokn3.dll to 
replace the mozilla one, you will be forever chacing the upstream 
version (Any new ciphers supported in firefox will wind up in 
softoken3.dll).


You could use the softoken source to build our own PKCS #11 module, 
though I would recommend using ckfw instead.


There are tools to help install your own PKCS #11 modules, and you don't 
have to update them everytime NSS updates.

look at:

In NSS itself, there's modutil:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/tools/NSS_Tools_modutil
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference/NSS_tools_:_modutil
http://lxr.mozilla.org/nss/source/cmd/modutil/

From the coolkey project, there's pk11install:
http://svn.fedorahosted.org/svn/coolkey/trunk/src/install/
This tools has code that searches for all your mozilla profiles and 
installs your module in them. Once installed, new version of Firefox 
will automatically inherit your PKCS #11 module.

Or it is meant only internal usage. If it can be
used as starting point then which methods should i override?
I'd suggest starting with capi or builtins as a better example of what 
you need to build a pkcs #11 module.


bob






--
View this message in context: 
http://mozilla.6506.n7.nabble.com/NSS-Custom-Crypto-Module-tp319226p319284.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS Custom Crypto Module

[Robert Relyea]

On 07/10/2014 01:28 AM, ramahmoo wrote:

I have a requirement where TLS client auth has to be done by client
certificate which is provided by a web-service (which in turn has access to
smart cards at central server location). To achieve this i want a custom
pkcs#11 crypto module that calls web service to get client certificate.
After searching all over i found this could be possible with NSS in cross
platform fashion. Using Firefox only is not a problem. Can i extend the
existing internal softtoken implementation to achieve the above? If yes
which methods has to be overriden. If no, from where should i start? What
about pin management in this case?I am newbie to PKCS#11 :) Thanks for your
help.
The plug in interface for this kind of thing is PKCS #11.  The current 
version of the PKCS #11 spec is available here:



 Docs

https://www.oasis-open.org/news/announcements/30-day-public-review-for-pkcs11-committee-specification-and-committee-note-drafts

It's a draft OASIS spec which is almost throught the OASIS process.

A short primer on implementing PKCS #11 for NSS is here: 
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/PKCS11_Implement
A supplemental FAQ is here: 
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/PKCS11/FAQ



 Samples

NSS code includes a toolkit for building PKCS #11 modules: nss/lib/ckfw. 
Under that directory are 3 examples:

nss/lib/ckfw/builtins - used to supply the builtin root certs.
nss/lib/ckfw/capi - used to access keys and certs stored in Microsoft 
CAPI on Windows.

nss/lib/ckfw/nssmkey - used to access keys and certs in the MacOS keyring.
You can brows these sources at : http://lxr.mozilla.org/nss/source/lib/ckfw/

The open-c project also has some tools and a helper library available 
here: http://lxr.mozilla.org/nss/source/lib/ckfw/










--
View this message in context: 
http://mozilla.6506.n7.nabble.com/NSS-Custom-Crypto-Module-tp319226.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Other ECC Curves

[Robert Relyea]

On 06/10/2014 09:47 AM, Kurt Roeckx wrote:
> On Mon, Jun 09, 2014 at 04:27:56PM -0700, Rick Andrews wrote:
>> AFAIK, Symantec and other CAs have added ECC roots to Mozilla's root store 
>> using NIST curves. Are any other ECC curves supported by Mozilla, in case 
>> one wanted to use a different curve? Is the list of supported algorithms and 
>> key sizes published somewhere?
> As far as I know NSS currently only supports P256, P384 and P521.

More exactly NSS can support the initial TLS suite of curves, but almost
all users (including mozilla and redhat) of NSS just compile the above 3
NIST curves.

>
> I would like to add brainpool to that, which should be easy.
>
> I would also like to see Ed25519, but there is no standard on how
> to do that yet.

Adding support for any curve within NSS should be relatively
straightforward. Convincing particular entities to ship with other
curves enable is another matter.

bob
>
>
> Kurt
>




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: ECC, FIPS Mode, and PKCS#11 devices

[Robert Relyea]

On 05/30/2014 11:55 AM, Jonathan Schulze-Hewett wrote:
> Another bit of oddness. I can put the PKCS#11 device into "read only" mode
> where it only supports CKS_RO_PUBLIC_SESSION and CKS_RO_USER_FUNCTIONS
> states and asserts the CKF_WRITE_PROTECTED flag. In this state Firefox
> attempts to call C_CreateObject to create an ECC public key on the device
> which fails. Firefox returns sec_error_bad_signature to the user in this
> case stating "Peer's certificate has an invalid signature."
RO only affects Token objects.
>
> Perhaps I misunderstand the meaning of those state and flag values and that
> read only/write protected means that callers can still make objects as long
> as CKA_TOKEN=false?
yes, those are ephemeral objects. In general, read only tokens need to
be to create those (sometimes explictily, like C_CreateObject, sometimes
implicitly, like C_Derive or C_Unwrap). These objects disappear if the
token is 'powered down', shutdown, removed, or all the sessions are
closed. Token objects stay on, thus require tokens that can be writeable.

bob
>
> Jonathan
>
>
>
>
> --
> View this message in context: 
> http://mozilla.6506.n7.nabble.com/ECC-FIPS-Mode-and-PKCS-11-devices-tp316591p316609.html
> Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: ECC, FIPS Mode, and PKCS#11 devices

[Robert Relyea]

On 05/30/2014 07:47 AM, Jonathan Schulze-Hewett wrote:
> To whom it may concern,
>
> I have a PKCS#11 device that supports ECC operations. In particular 
> C_GetMechanismList includes the following items:
>
> CKM_ECDH1_DERIVE
> CKM_ECDH1_COFACTOR_DERIVE
> CKM_EC_KEY_PAIR_GEN
> CKM_ECDSA
>
> The module is added to Firefox using nsIPKCS11::addModule with 0 for both the 
> cryptoMechanismFlags and the cipherFlags.
>
> If I put Firefox into FIPS mode it uses my PKCS#11 module to perform ECC 
> computations during TLS negotiation where ecdhe is being preferred by the 
> server. In particular, it will call C_GenerateKeyPair (to generate an ECC key 
> pair), C_DeriveKey (to derive a shared secret), C_GetAttributeValue (to 
> obtain the shared secret), C_CreateObject (to add an RSA public key for some 
> reason), and C_WrapKey (to wrap the secret key with the recently added RSA 
> key).
>
> Fundamentally I think this should work, but Firefox tends to "hang" after 
> C_WrapKey returns. That's something that I'm continuing to examine. Anyway, 
> the crux of the problem with respect to this mailing list is that I don't 
> think Firefox should be using the token to perform these operations as I set 
> flags in addModule to 0. 
>
> Any guidance on this issue you can provide is most welcome.
>
> Thanks in advance,
> Jonathan
>
Hi Jonathan,

Fundamentally, I think you are right. There were some bugs where ECC
wasn't using the prefered flags properly. Which version of Firefox?

The other possible issue may be the curves. Which curves do you support
, and which are you negotiating in the TLS operation?

bob



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS fails to compile on MIPS64 n32 platforms

[Robert Relyea]

On 05/15/2014 02:31 AM, Vicente Olivert Riera wrote:
> On 05/15/2014 10:11 AM, Vicente Olivert Riera wrote:
>>> We usually do cross compiles by creating a cross target .mk file
>>> (MIPS_CROSS.mk for instance). You can include linux.mk and explicitly
>>> set the CPU_ARCH inside there. (see android.mk).
>>>
>>> bob
>>
>> Ok, I will have a look at it.
>>
>
> Hi Robert,
>
> I have written a patch to set the target architecture by passing the
> CROSS_ARCH variable to the make command, like this:
>
> make CROSS_ARCH=mips64
>
> So the patch is as follows:
>
> ## BEGIN PATCH 
> diff -rNup a/mozilla/security/coreconf/cross_arch.mk
> b/mozilla/security/coreconf/cross_arch.mk
> --- a/mozilla/security/coreconf/cross_arch.mk1970-01-01
> 01:00:00.0 +0100
> +++ b/mozilla/security/coreconf/cross_arch.mk2014-05-15
> 10:19:10.790494268 +0100
> @@ -0,0 +1,10 @@
> +#
> +# This Source Code Form is subject to the terms of the Mozilla Public
> +# License, v. 2.0. If a copy of the MPL was not distributed with this
> +# file, You can obtain one at http://mozilla.org/MPL/2.0/.
> +
> +include $(CORE_DEPTH)/coreconf/Linux.mk
> +
> +ifdef ($(CROSS_ARCH))
> +CPU_ARCH = $(CROSS_ARCH)
> +endif
> ### END PATCH #
>
> Do you think this patch could get upstream too?
I'm OK with it, I'd like wtc to way in. Go ahead and do the same
process, actually you could probably attach it to the same bug you used
for the compile problem.

bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS fails to compile on MIPS64 n32 platforms

[Robert Relyea]

On 05/14/2014 03:57 AM, Vicente Olivert Riera wrote:
> On 05/13/2014 07:20 PM, Robert Relyea wrote:
>> On 05/13/2014 03:42 AM, Vicente Olivert Riera wrote:
>>> Hi Paul,
>>>
>>> I think I have fixed the problem.
>>>
>>> The failure comes from this file
>>> "mozilla/security/nss/lib/freebl/drbg.c" on the line #512, which has
>>> an assert of the size of "size_t":
>>>
>>> PR_STATIC_ASSERT(sizeof(size_t) > 4)
>>>
>>> That line is inside an #if/#endif block which has this form:
>>>
>>> #if defined(NS_PTR_GT_32) || (defined(NSS_USE_64) &&
>>> !defined(NS_PTR_LE_32))
>>>
>>> So, that code is being executed because "NSS_USE_64" is true.
>>>
>>> The problem is that in MIPS64 n32 the size of size_t is exactly 4 (is
>>> an unsigned integer of 32 bits), and then that assert fails.
>>>
>>> But, the mechanism to fix that is already present. If you look more
>>> carefully at the #if statement you will see this at the end:
>>>
>>> !defined(NS_PTR_LE_32)
>>>
>>> That macro is for 64-bit architectures that use 32-bit pointers, which
>>> is exactly the case of MIPS64 n32. So, to fix the problem we only need
>>> to detect when we are building for MIPS64 n32, and then define that
>>> macro so the #if statement will fail and the #else will be executed
>>> instead. Here you have a patch that I have already tested to check if
>>> it works, and it worked. The thing is that I don't know where is the
>>> best place to put those lines, so I would like a bit of feedback here.
>> The better fix is to add NS_PTR_LE_32 the Makefile in freebl (that's
>> where most of the platform dependent choices are made).
>>
>> ifeq ($CPU_ARCH,mips)# or whatever the appropriate define is for
>> mips64 n32.
>>  DEFINES += -DNS_PTR_LE_32
>> endif
>>
>> There may be new checks in nss freebl that have the same character.
>> Better to make the definition more general.
>>   AFAIK this is the first platform the actually required the
>> NS_PTR_LE_32
>> or NS_PTR_GT_32 define.
>>
>> bob
>
> Hello bob,
>
> this patch would fix the problem for native compilations:
>
> ## BEGIN PATCH 
> diff -rup a/mozilla/security/nss/lib/freebl/Makefile
> b/mozilla/security/nss/lib/freebl/Makefile
> --- a/mozilla/security/nss/lib/freebl/Makefile2013-01-31
> 01:08:59.0 +
> +++ b/mozilla/security/nss/lib/freebl/Makefile2014-05-14
> 10:31:02.622338772 +0100
> @@ -206,6 +206,11 @@ ifeq ($(CPU_ARCH),arm)
>  DEFINES += -DSHA_NO_LONG_LONG # avoid 64-bit arithmetic in SHA512
>  MPI_SRCS += mpi_arm.c
>  endif
> +ifeq ($(CPU_ARCH),mips64)
> +ifeq ($(USE_N32),1)
> +DEFINES += -DNS_PTR_LE_32
> +endif
> +endif
>  endif # Linux
>
>  ifeq ($(OS_TARGET),AIX)
> ### END PATCH #

Please write a bug on this (mozilla.bugzilla.com), attach this patch and
request a review from me (rrelyea). We can get this upstream.

Thanks,
bob
>
> The user would need to pass USE_N32=1 to the make command, but I think
> that's reasonable.
>
> Now we have another problem. That will fail when cross-compiling
> because the $CPU_ARCH variable comes from $OS_TEST (see
> mozilla/security/coreconf/Linux.mk for details) which comes from
> `uname -m` (see mozilla/security/coreconf/arch.mk for details). So,
> when you are cross-compiling the result of `uname -m` is the
> architecture of the host machine, not the target machine.
>
> Could be possible to add another user-defined variable to set the
> target architecture and do something like this in the Linux.mk file?
>
> ifdef($TARGET_ARCH)
>   CPU_ARCH=$TARGET_ARCH
> else
>   CPU_ARCH=$OS_TEST
> endif
>
> In that case the use would need to pass TARGET_ARCH=mips64 to the make
> command. (mips64 is just an example in this case)
We usually do cross compiles by creating a cross target .mk file
(MIPS_CROSS.mk for instance). You can include linux.mk and explicitly
set the CPU_ARCH inside there. (see android.mk).

bob
>
>>>
>>>
>>>
>>> diff -rup a/mozilla/security/nss/lib/freebl/drbg.c
>>> b/mozilla/security/nss/lib/freebl/drbg.c
>>> --- a/mozilla/security/nss/lib/freebl/drbg.c2012-12-12
>>> 19:22:39.0 +
>>> +++ b/mozilla/security/nss/lib/freebl/drbg.c2014-05-13
>>> 11:24:32.100993252 +0100
>>> @@ -485,6 +485,10 @@ RNG_RandomUpdate(const void *data, size_
>>>   /* Make sure 

Re: NSS fails to compile on MIPS64 n32 platforms

[Robert Relyea]

On 05/13/2014 03:42 AM, Vicente Olivert Riera wrote:
> Hi Paul,
>
> I think I have fixed the problem.
>
> The failure comes from this file
> "mozilla/security/nss/lib/freebl/drbg.c" on the line #512, which has
> an assert of the size of "size_t":
>
> PR_STATIC_ASSERT(sizeof(size_t) > 4)
>
> That line is inside an #if/#endif block which has this form:
>
> #if defined(NS_PTR_GT_32) || (defined(NSS_USE_64) &&
> !defined(NS_PTR_LE_32))
>
> So, that code is being executed because "NSS_USE_64" is true.
>
> The problem is that in MIPS64 n32 the size of size_t is exactly 4 (is
> an unsigned integer of 32 bits), and then that assert fails.
>
> But, the mechanism to fix that is already present. If you look more
> carefully at the #if statement you will see this at the end:
>
> !defined(NS_PTR_LE_32)
>
> That macro is for 64-bit architectures that use 32-bit pointers, which
> is exactly the case of MIPS64 n32. So, to fix the problem we only need
> to detect when we are building for MIPS64 n32, and then define that
> macro so the #if statement will fail and the #else will be executed
> instead. Here you have a patch that I have already tested to check if
> it works, and it worked. The thing is that I don't know where is the
> best place to put those lines, so I would like a bit of feedback here.
The better fix is to add NS_PTR_LE_32 the Makefile in freebl (that's
where most of the platform dependent choices are made).

ifeq ($CPU_ARCH,mips)# or whatever the appropriate define is for
mips64 n32.
DEFINES += -DNS_PTR_LE_32
endif

There may be new checks in nss freebl that have the same character.
Better to make the definition more general.
 AFAIK this is the first platform the actually required the NS_PTR_LE_32
or NS_PTR_GT_32 define.

bob
>
>
>
> diff -rup a/mozilla/security/nss/lib/freebl/drbg.c
> b/mozilla/security/nss/lib/freebl/drbg.c
> --- a/mozilla/security/nss/lib/freebl/drbg.c2012-12-12
> 19:22:39.0 +
> +++ b/mozilla/security/nss/lib/freebl/drbg.c2014-05-13
> 11:24:32.100993252 +0100
> @@ -485,6 +485,10 @@ RNG_RandomUpdate(const void *data, size_
>  /* Make sure our assumption that size_t is unsigned is true */
>  PR_STATIC_ASSERT(((size_t)-1) > (size_t)1);
>
> +#if defined(__mips__) && defined(_ABIN32)
> +#define NS_PTR_LE_32
> +#endif
> +
>  #if defined(NS_PTR_GT_32) || (defined(NSS_USE_64) &&
> !defined(NS_PTR_LE_32))
>  /*
>   * NIST 800-90 requires us to verify our inputs. This value can
>
>
>
> On 05/13/2014 09:16 AM, Vicente Olivert Riera wrote:
>> On 05/13/2014 01:56 AM, Paul Wouters wrote:
>>> On Mon, 12 May 2014, Vicente Olivert Riera wrote:
>>>
> Are you compiling natively? Or cross compiling? This is on my todo
> list
> (as prereq for libreswan) but after a quick first attempt and seeing
> that it compiles/runs some code with no check that it is cross
> compiling
> had demotivated me enough to postpone it.

 Hi Paul,

 I'm cross compiling.
>>>
>>> Hmm, interesting. If you do get it to work let me know. If I pick this
>>> up again in a few weeks and make it work, I'll let you know.
>>
>> It works on MIPS32 and MIPS64 n64 ABI. It only fails on MIPS64 n32 ABI.
>> Maybe it's not a bug of NSS but NSPR. Please have a look to this thread
>> which is about the same failure (and there is a patch at the end to fix
>> it):
>>
>> http://lists.busybox.net/pipermail/buildroot/2013-March/068973.html
>>
>> patch: nspr-prcpucfg-aarch64.patch
>> http://pastie.org/6606946
>>
>>> Paul
>>>
> Paul
>
>> Date: Mon, 12 May 2014 11:33:13
>> From: Vicente Olivert Riera 
>> To: dev-tech-crypto@lists.mozilla.org
>> Subject: NSS fails to compile on MIPS64 n32 platforms
>>
>> I'm trying to build NSS-3.14.5 on Buildroot for MIPS54 n32 ABI
>> and I'm
>> getting this compilation failure:
>>
>> 
>> In file included from
>> /home/test/test/1/output/host/usr/mips64el-buildroot-linux-gnu/sysroot/usr/include/nspr/prerror.h:9:0,
>>
>>
>>
>>
>> from drbg.c:10:
>> drbg.c: In function 'RNG_RandomUpdate':
>> /home/test/test/1/output/host/usr/mips64el-buildroot-linux-gnu/sysroot/usr/include/nspr/prtypes.h:560:38:
>>
>>
>>
>> error: size of array 'arg' is negative
>> extern void pr_static_assert(int arg[(condition) ? 1 : -1])
>>  ^
>> drbg.c:512:5: note: in expansion of macro 'PR_STATIC_ASSERT'
>> PR_STATIC_ASSERT(sizeof(size_t) > 4);
>> ^
>> make[4]: ***
>> [Linux2.6_mips64el_glibc_PTH_64_OPT.OBJ/Linux_SINGLE_SHLIB/drbg.o]
>> Error 1
>> 
>>
>> This is the full build log:
>>
>> http://autobuild.buildroot.net/results/0e3/0e3f1482d6f2f9bddc53d4e78b575120a2729e1d/build-end.log
>>
>>
>>
>>
>>
>> I also tried NSS-3.16.1 and I got the same

Re: TLS 1.2 / PR_Write

[Robert Relyea]

On 04/17/2014 04:46 PM, james brown wrote:
> Hi
>
> I'm a little bit confused about the differences in implementation of SSL v3
> and TLS 1.2
>
> In Firefox when you visit a website with SSL v3 the data sent through
> PR_Write is in plaintext and later to be encrypted in Ssl_Write (as far as
> I know)
>
> But on a TLS 1.2 site when PR_Write is called the data is already encrypted
>
> Could someone help me understand what's going on here?
What you are describing doesn't sound right. I suspect the issue isn't
an SSL v3 versus TLS but something else. Without knowing what data you
are talking about it's now clear what you are seeing, so the following
are pure guesses:

1) First, there is no basic difference in SSL v3 and TLS in how the
handshake works with respect to switching to an encrypted connection. In
both the handshake starts out unencrypted because there is no history of
keys between the two sides. Once a handshake has completed, the data is
now encrypted. No data from the initial write is sent unencrypted. If
you later want to renegotiate (say change from SSLv3 to TLS) on the same
connection, that entire handshake will happen using the previous (say
SSLv3) SSL cipher and then change to the new one before any additional
data is sent.

If you are snooping the packets, you will first see the unencrypted
handshake messages, and then the always encrypted messages.

2) If you create a connection to a server, then create a connection to a
second connection to the same server, the second connection will usually
have use the same master key and derive new session keys in an
abbreviated handshake. It is possible you are making your first
connection to the server using SSL v3 and a second using TLS 1.2 (though
doing this would require an unusual set of circumstances). The second is
a restart handshake, which is shorter and may look encrypted at first
look, but it's actually not encrypted.

3) Your SSL3 server is doing something different than your TLS server.
For instance, you may be connecting to it using http:// and it's
redirecting using https://. The entire http:// portion will be
unencrypted because that is what http:// means. You could also be
connecting using starttls. We don't typically use starttls for
http/https (I don't actually think it works there), but imap and ldap
use starttls. In that case the connection starts completely unencrypted
until the starttls message is sent and then the SSL handshake and then
the data is encrypted.

This is not an exhaustive list, but the important point here is if you
are seeing unencrypted data followwed by encrypted data, it's not a SSL
v3 versus TLS 1.2 issue, it's some other SSL/TLS/HTTP thing going on.
Also, you shouldn't have any cases where the data you actually send in
PR_Write is sent unencrypted.
>
> Why is the data not encrypted after PR_Write like with SSL v3?




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Chrome: From NSS to OpenSSL

[Robert Relyea]

On 04/08/2014 06:31 AM, Alan Braggins wrote:
> On 08/04/14 13:11, Jean-Marc Desperrier wrote:
>> Ryan Sleevi a écrit :
>>> reliance on PKCS#11 means that there are non-trivial overheads when
>>> doing something as "simple" as hashing with SHA-1. For something
>>> that is
>>> such a "simple" transformation, multiple locks must be acquired and the
>>> entire NSS internals may*block*  if using NSS on multiple threads, in
>>> order to prevent any issues with PKCS#11's threading design.
>>
>> I don't believe that PKCS#11's threading design mandates that.
>> Implementation easily can have that problem, and NSS sure does, but I
>> think it would be possible to design a PKCS#11 implementation than let's
>> you do hashing without requiring locks.
>> Or maybe, it's more because of PKCS#11 session management rules that you
>> hardly can avoid them.
>
> If you do all your hashing in one session, then the rules require
> you to use locks. The obvious answer is "don't do that then", but
> PKCS#11 libraries for dumb devices are allowed to only support a
> limited number of sessions and force you to juggle C_GetOperationState/
> SetOperationState.
>
> But if https://developer.mozilla.org/en/docs/PKCS11_FAQ is accurate,
> it will only fall back on the single session solution if the device
> requires it.
>
> And for hashing without secret keys (plain digest, not HMAC, no
> C_DigestKey calls), there's never any reason to use a limited device
> for that operation.
>
To be clear, for any token that supports multiple sessions, NSS only
grabs an uncontended session lock. NSS does that not because of PKCS #11
semanatics, but because applications sometimes gets the threading wrong.
If you are contending on that lock it's because the application messed
up and tried to do two operations on the same context at the same time.
The lock isn't grabbed because it's needed by NSS, only because
applications get this kind of thing wrong a lot. Same with the NSS locks
in SSL.

bob



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cryptoki interface to decrypt mail with thunderbird

[Robert Relyea]

On 03/18/2014 04:29 AM, Leon Brits wrote:
> Robert,
>
> Thanks for your help. This discussion has helped me to find the error in our 
> padding implementation for symmetric ciphers using OpenSSL which defaults to 
> "always pad".
>
> Encryption and decryption via thunderbird now works just fine.

go ahead and right a bug against NSS not calling Final in the error path
for S/MIME as well.

Your semantic is correct for CKM_XXX_CBC_PAD mechanism. NSS only uses
those, however to do private key wrapping.

bob
>
> Thanks
> LJB
>




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cryptoki interface to decrypt mail with thunderbird

[Robert Relyea]

On 03/14/2014 04:42 AM, Leon Brits wrote:
> Robert,
>
> Thanks for your time.
>
>> cmscipher does call DecryptUpdate, but for the symmetric portion, not the
>> asymmetric portion. We were talking about key unwrapping/decrypt in RSA.
>> This is clearly an symmetric operation (DES3 or AES or something).
> Ok. Sorry if I misunderstood and gave the incorrect answer.
>
>> Looks like you are trying use a PAD mechanism when NSS requested a CBC
>> mechanism. In the CBC mechanism NSS will always ask for even number of
>> blocks and expect to get back all the blocks. In the PAD mechanism, the
>> PKCS #11 module needs to hold back one block in order to handle padding
>> correctly.
> I simply provide the PKCS11 interface, Thunderbird must decide which PKCS#11 
> call to do. In thunderbird I encrypted a message and now I want to decrypt it 
> on another machine with Thunderbird. I only told Thunderbird which RSA 
> certificate is used as the targeted party. So if Thunderbird now wants to 
> decrypt it should know what it did and make the right PKCS#11 calls.
What you supply is important. If you supply more of the PKCS #11
interface, then you need to implement what you supply correctly. That's
fine to do. If you just implement the minimum, Thunderbird will use
softoken (which has a correct implementation of C_DecryptUpdate for
AES_CBC). NSS tries to keep the operation in the token with the key and
only moves it when necessary. If you don't want this to happen, you need
to 'break the chain' somewhere. If you're OK with proceding with the
rest of the operation, then you just need to make sure you are doing
PKCS #11 correctly. That means if I ask for C_Decrypt on CKM_AES_CBC, if
I give you full blocks, you need to return all the blocks (you don't
hold one back).
>  I got the DecryptUpdate() call which means Thunderbird must call the 
> DecryptFinal() at some point (IMO).

It looks like we do have an issue in the error path, but fixing that
won't make your token work. If we are bailing it's because you
incorrectly implemented DecryptUpdate(). We'll just close out the session.
>
>> Can't call decrypt here, because I probably have more blocks coming.
>> This is encrypting the email message, so it's streaming.
> It is decrypting.

It's a streaming decryption. We get data sent from Thunderbird
piecemeal. There are lots more blocks we need to decrypt, the few blocks
you have are not all there is. If you implemented C_DecryptUpdate
correctly for the mechanism we requested, you would get another
C_DecryptUpdate call.
>
>> The fundamental issue here is you are probably trying to do more than you
>> need to if you just want a signing/decryption token. You don't need to
>> implement the symmetric algorithms, so if you just implement decrypt
>> (rather than unwrap), NSS will use it's internal implementation to do the
>> symmetric operations.
NOTE: Please read this paragraph. This is where you are having the
problems. Once you fix this, you will get a proper C_DecryptFinal(),
life will be fine.
>>
>> If you are trying to build a full replacement (because you are managing
>> the keys in your token or something, then you need to return all the
>> blocks requested when doing a CBC operation (rather then a CBC_PAD
>> operation).
> We do have a VERY complete implementation of RSA, DSA, DH, EC, wrap/unwrap, 
> en/decrypt, sign/verify and derivation on our device. We expose this all via 
> PKCS#11 v2.2 and up.
That's fine, but you need to implement C_DecryptUpdate correctly. If you
just want things to 'work', you could simply just drop wrap/unwrap from
your RSA support. NSS will decrypt and insert the decrypted key into
softoken.
>  And for them all, if you call DecryptUpdate() then you must call 
> DecryptFinal(). As far as I know this is the standard. Please correct me if I 
> wrong.
That is correct, please write a bug against the fact that we  fail to
finalize on our error path. Be aware, however, that once we fix this
bug, you will still have problem decrypting because we are in the
process here of shutting down the connection. You will get the
C_DecryptFinal call, but we S/MIME will still fail to work with your token.
 t
>
> Regards,
> LJB
>




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cryptoki interface to decrypt mail with thunderbird

[Robert Relyea]

On 03/13/2014 05:12 AM, Leon Brits wrote:
> Robert,
>
> Attached is a log of the backtrace when I try to use Thunderbird to decrypt 
> an email. As you can see in the log it reaches C_DecryptUpdate(), but then 
> asserts at cmscipher.c:452.

I don't see the attachment? did you forget or did the mailing list strip it?

> Now we use OpenSSL to perform these cryptographic operations and if you give 
> its DecryptUpdate() function exactly (N * blocksize) of data then it will 
> keep 1 block back waiting for either a DecryptUpdates() with more data or a 
> DecryptFinal() at which stage it will return the plaintext of that last block.
cmscipher does call DecryptUpdate, but for the symmetric portion, not
the asymmetric portion. We were talking about key unwrapping/decrypt in
RSA. This is clearly an symmetric operation (DES3 or AES or something).

Looks like you are trying use a PAD mechanism when NSS requested a CBC
mechanism. In the CBC mechanism NSS will always ask for even number of
blocks and expect to get back all the blocks. In the PAD mechanism, the
PKCS #11 module needs to hold back one block in order to handle padding
correctly.
>
> So what I think is happening here is that you call DecryptUpdate() with data 
> which fall on the blocksize boundary and OpenSSL buffer the last blocksize of 
> data and you expect everything back and therefore asserts. My question then 
> is why do you call DecryptUpdate() here. A Decrypt() would solve my problem.
Can't call decrypt here, because I probably have more blocks coming.
This is encrypting the email message, so it's streaming.


The fundamental issue here is you are probably trying to do more than
you need to if you just want a signing/decryption token. You don't need
to implement the symmetric algorithms, so if you just implement decrypt
(rather than unwrap), NSS will use it's internal implementation to do
the symmetric operations.

If you are trying to build a full replacement (because you are managing
the keys in your token or something, then you need to return all the
blocks requested when doing a CBC operation (rather then a CBC_PAD
operation).

bob
>
> Thanks for your time!
> Regards,
> LJB
>
>
>
>
>




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: initializing the standalone nss soft token (libsoftokn3.so)

[Robert Relyea]

On 03/10/2014 08:50 PM, Dave wrote:
> I'm having trouble initializing the nss soft token when linking against it 
> directly.  The function _NSSUTIL_EvaluateConfigDir (utilpars.c) is 
> segfaulting when passing the following initialization arguments to 
> C_Initialize:
>
>   CK_CHAR * configString = (unsigned char *)
>   "configdir='/tmp/' certPrefix='prefix1' keyPrefix='prefix2' 
> secmod='secmod.db' flags='readonly,forceopen' ";
>   CK_C_INITIALIZE_ARGS ck_init_args;
>   ck_init_args.CreateMutex = NULL;
>   ck_init_args.DestroyMutex = NULL;
>   ck_init_args.LockMutex = NULL;
>   ck_init_args.UnlockMutex = NULL;
>   ck_init_args.flags = CKF_OS_LOCKING_OK;
>   ck_init_args.LibraryParameters=&configString;
>   ck_init_args.pReserved=NULL;
>
> I'm building against the ubuntu version: 2:3.15.4-1ubuntu6 on an x86_64 
> machine.
>
> What is the correct formatting of the LibraryParameters string passed via 
> CK_C_INITIALIZE_ARGS to C_Initialize? 

ck_init_args.LibraryParameters=&configString;

should be

ck_init_args.LibraryParameters=configString;






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cryptoki interface to decrypt mail with thunderbird

[Robert Relyea]

On 03/10/2014 12:48 AM, Leon Brits wrote:
> Hi Robert,
>
> Thanks for the reply.
>
>> ...I'm assuming we are talking
>> about an RSA operation here and not an symetric key operation like AES or
>> DES.
> Yes RSA.
>
>> Yes, I just checked. We we are unwrapping a key (which is what the logical
>> function RSA Decrypt supports), We check to see if the token support
>> unwrap with the target mechanism
> We do support the "Unwrap" function and the sequence of function calls in my 
> original mail is steps after a successful unwrap. I guess thunderbird now 
> wants to use the unwrapped key to decrypt the email.
>
> So the question remains: Why if C_DecryptUpdate() is called, is 
> C_DecryptFinal() not called? If there is only one block then C_Decrypt() 
> should have been called - right?
I don't know why you are seeing C_DecryptUpdate() because the code
doesn't call it when doing unwrap, it only calls C_Decrypt.
>
> We do implement C_Decrypt(), C_DecryptUpdate() and C_DecryptFinal() (we have 
> to support PKCS#11 v2.2 and up).
> I've verified that the order of the functions (in CK_FUNCTION_LIST) is 
> correct. C_Sign() works, which is define after C_DecryptFinal().

So I don't understand why you are seeing C_DecryptUpdate() in this case,
unless you call C_DecryptUpdate() internally from your PKCS #11 module
from C_Decrypt(). If you could build or acquire a debug version of
Firefox and set a break point in C_DecryptUpdate() and give a stack
traceback, that would be helpful to understanding what is going on.

bob
>
> Regards,
> LJB
>




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cryptoki interface to decrypt mail with thunderbird

[Robert Relyea]

On 03/07/2014 07:02 AM, Leon Brits wrote:
> Hi,
>
> We have a security device which is used via cryptoki (PKCS#11) to perform 
> cryptographic operations such as sign/verify and en/decrypt of emails.
> Sign works via our device while Verify and Encrypt is done by the PC. Our 
> problem is with Decrypt: We never get a 'DecryptFinal()' function call. From 
> the debug log I can see that the DecryptInit() function is called and 
> successfully exits. Next a DecryptUpdate() is called and all the data is send 
> to our device with APDU and even this finishes successful. Next 
> C_CloseSession() is called instead of DecryptFinal() first. Am I wrong to 
> expect this?
Hmm. This is interesting, I would have expected NSS to do a
C_DecryptInit() followed by a C_Decrypt(). I'm assuming we are talking
about an RSA operation here and not an symetric key operation like AES
or DES.

Yes, I just checked. We we are unwrapping a key (which is what the
logical function RSA Decrypt supports), We check to see if the token
support unwrap with the target mechanism. If it does we use unwrap (and
the key winds up in the token). If the token does not support unwrap,
but it does support decrypt, we call our 'handunwrap' routine with
decrypts the key and then inserts the decrypted in into an appropriate
token. The decrypt happens with the following sequence:

C_CreateSession()
C_DecryptInit()
C_Decrypt()
C_CloseSession()

I wonder if your token is mapping C_Decrypt to C_DecryptUpdate ?

(See pk11_handUnwrap() in nss/lib/pk11wrap/pk11skey.c)

bob
>
> Please help
> Regards,
> LJB
>
>




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SSL objects and NSS code communicating with PKCS#11 module

[Robert Relyea]

On 03/05/2014 01:21 AM, Raad Bahmani wrote:
> Hello Robert,
>
> thank your for your answer !
>
> 
>>> 3) Which algorithm is used for login with SSL ?
>> I'm not sure what you mean by 'login with SSL'. Do you mean create an
>> SSL handshake? do you  mean client auth? do you mean login to the token
>> to use SSL?
> you are right, my question is vaguely formulated !
> I guess it would be: "client authentication"
>
> This is the scenario:
>
> 1) A user opens a web-page where he can log in using his SSL certificate.
> 2) He clicks on a link which says: "Log-In with SSL Certificate".
> 3) Firefox handles this request by calling functions of my PKCS#11 module.
>
> Where do I find the code which calls the functions of my module?

You don't need to implement the SSL key exchange algorithms for this,
you simply need to implement signing.

Your best bet is: https://developer.mozilla.org/en-US/docs/PKCS11_Implement
Your token profile is 'Signing tokens'

When you see requests for attributes or objects that aren't part of the
PKCS #11 spec, you should respond as the PKCS #11 spec directs for
unknown attributes and objects. NOTE: if you have a list of mixed
attributes, PKCS #11 requires you to fill in all the attributes you do
understand and mark the ones you don't with length of -1.

These additional attributes are not necessary to be able to create
client auth connections.
>
>
>
> 
>>> C_FindObjects with:
>>> session-handle: 100
>>> ulMaxObjectCount: 1
>> What did you return here? This is a very basic Find object call looking
>> for an object that you probably don't support, You should return no
>> object here.
> As I mentioned, my module *simulates* a smart-card, so always a dummy
> ID/Handle is returned when for example a session is required to be
> created or when the  C_FindObjects  is called.
>
> If a dummy object-handle is not returned the firefox keeps calling the
> C_Find* functions as you can see bellow.

Once your token is loaded, firefox will ask it for all sorts of objects.
If you don't know the object, you should always return 'no such object'.
If you pretend to return an object you don't know about, things will not
end well...

In simulating a smart card, do you claim to be a hardware device? If so
NSS will just ask you at token insertion of a full range of objects
ahead of time and then never bother you (assuming you have only a small
number of certs/crls/etc).

What I see below is exactly what I expect (NSS asking you, do you know
this cert? do you have the CRL for this CA, etc.). You should expect to
see these calls continually if you are functioning correctly.

bob
>
>
>
>
>
> msg 29: C_GetSlotInfo
> msg 30: C_FindObjectsInit with:
> msg 31: session-handle: 100l
> msg 32: ulCount: 4l
> msg 33: template 
> msg 34: --
> msg 35: Attr0 Type L: 1l
> msg 36: Attr0 Type X: 1l
> msg 37: Attr0 Value L: 1l
> msg 38: Attr0 Value X: 1
> msg 39: Attr0 ulValueLen: 1l
> msg 40: --
> msg 41: Attr1 Type L: 0l
> msg 42: Attr1 Type X: 0l
> msg 43: Attr1 Value L: 1l
> msg 44: Attr1 Value X: 1
> msg 45: Attr1 ulValueLen: 8l
> msg 46: --
> msg 47: Attr2 Type L: 129l
> msg 48: Attr2 Type X: 129l
> msg 49: Attr2 Value L: 831291696l
> msg 50: Attr2 Value X: 318c8130
> msg 51: Attr2 ulValueLen: 143l
> msg 52: --
> msg 53: Attr3 Type L: 130l
> msg 54: Attr3 Type X: 130l
> msg 55: Attr3 Value L: 235733762l
> msg 56: Attr3 Value X: e0d0302
> msg 57: Attr3 ulValueLen: 5l
> msg 58: C_FindObjects with:
> msg 59: session-handle: 100l
> msg 60: ulMaxObjectCount: 1l
> msg 61: C_FindObjectsFinal (100l)
> msg 62: C_FindObjectsInit with:
> msg 63: session-handle: 100l
> msg 64: ulCount: 4l
> msg 65: template 
> msg 66: --
> msg 67: Attr0 Type L: 1l
> msg 68: Attr0 Type X: 1l
> msg 69: Attr0 Value L: 1l
> msg 70: Attr0 Value X: 1
> msg 71: Attr0 ulValueLen: 1l
> msg 72: --
> msg 73: Attr1 Type L: 0l
> msg 74: Attr1 Type X: 0l
> msg 75: Attr1 Value L: 1l
> msg 76: Attr1 Value X: 1
> msg 77: Attr1 ulValueLen: 8l
> msg 78: --
> msg 79: Attr2 Type L: 129l
> msg 80: Attr2 Type X: 129l
> msg 81: Attr2 Value L: 831291696l
> msg 82: Attr2 Value X: 318c8130
> msg 83: Attr2 ulValueLen: 143l
> msg 84: --
> msg 85: Attr3 Type L: 130l
> msg 86: Attr3 Type X: 130l
> msg 87: Attr3 Value L: 15470093l
> msg 88: Attr3 Value X: ec0e0d
> msg 89: Attr3 ulValueLen: 3l
> msg 90: C_FindObjects with:
> msg 91: session-handle: 100l
> msg 92: ulMaxObjectCount: 1l
> msg 93: C_FindObjectsFinal (100l)
> msg 94: C_FindObjectsInit with:
> msg 95: session-handle: 100l
> msg 96: ulCount: 4l
> msg 97: template 
> msg 98: --
> msg 99: Attr0 Type L: 1l
> msg 100: Attr0 Type X: 1l
> msg 101: Att

Re: NSS algorithm performance

[Robert Relyea]

On 03/04/2014 03:54 PM, Julien Pierre wrote:
> Did anyone ever write a script that measures the performance of all
> the low-level algorithms in freebl, and collects the data in a way
> that's easy to compare ? This would probably be using bltest.
> This is for the purpose of evaluating different compilers/optimization
> options.
> If so, sharing would be much appreciated.
>
Nelson did. They are under the nss/tests/ciphers. It uses bltest. I
believe it was turned off because bltest couldn't handle the corner case
of leading zeros in RSA operations, which lead to periodic failures of
the tests, but you can still run performance.sh yourself. I used it to
test the performance of the AES-NI code when it was added.

bob



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SSL objects and NSS code communicating with PKCS#11 module

[Robert Relyea]

On 03/03/2014 04:31 AM, Raad Bahmani wrote:
> Hello together,
>
> I need to implement a PKCS11-library which simulates a smart-card and
> responds to login attempts with SSL certificates.
>
> I have found out that SSL needs the following mechanisms, so the
> "C_GetMechanismList" of my library specifies them as supported.
>
> - CKM_SSL3_PRE_MASTER_KEY_GEN
> - CKM_SSL3_MASTER_KEY_DERIVE
> - CKM_SSL3_KEY_AND_MAC_DERIVE
> - CKM_SSL3_MD5_MAC
> - CKM_SSL3_SHA1_MAC
>
> When trying to login using SSL the following functions are called before
> the firefox crashes ! :/
>
> These are my questions:
>
> 1) What are these objects: ce534354, ce534353,  b316030,
> 102, 318c8130, e0d0302
It's not clear without context. These look like they could either be
object ID's or Attribute ID's.
The ones starting with ce5343xx are NSS specific attributes or objects.
Your library can reject or ignore them (depending on context. 102 looks
like a regular PKCS #11 addribute or id (depending on context). The
others look like memory addresses, so there's nothing I can really tell
about them. NSS never used those as PKCS #11 id's
> 2) Where can I find (in cross-reference ) the source code of firefox/NSS
> which communicates with my library ?
The NSS specific id's are defined in lib/util/pkcs11n.h
> 3) Which algorithm is used for login with SSL ?
I'm not sure what you mean by 'login with SSL'. Do you mean create an
SSL handshake? do you  mean client auth? do you mean login to the token
to use SSL?
>
> Thank you in advance.
> - Raad
>
>
>
>
> +---
> C_GetFunctionList
> +---
> C_Initialize
> +---
> C_GetInfo
> +---
> C_GetSlotList
> +---
> C_GetSlotList
> +---
> C_GetSlotInfo
> +---
> C_GetTokenInfo
> +---
> C_GetMechanismList
> +---
> C_OpenSession with:
> lag: 4l
> slotId: 22l
> +---
> C_FindObjectsInit with:
> session-handle: 100
> ulCount: 1
> Attr0 Value: ce534354
> +---
> C_FindObjects with:
> session-handle: 100
> +---
> C_FindObjectsFinal
> +---
> C_GetSlotInfo
> +---
> C_FindObjectsInit with:
> session-handle: 100
> ulCount: 4
>
> template 
> Attr0 Type: 1
> Attr0 Value: 1
> Attr0 ulValueLen: 1
> --
> Attr1 Type: 0l
> Attr1 Value: ce534353
> Attr1 ulValueLen: 8
> --
> Attr2 Type: 129l
> Attr2 Value: b316030
> Attr2 ulValueLen: 98l
> --
> Attr3 Type: 130l
> Attr3 Value: 102
> Attr3 ulValueLen: 3l
> +---
> C_FindObjects with:
> session-handle: 100
> ulMaxObjectCount: 1

What did you return here? This is a very basic Find object call looking
for an object that you probably don't support, You should return no
object here.
> +---
> C_FindObjectsFinal
> +---
> C_FindObjectsInit with:
> session-handle: 100l
> ulCount: 4l
>  template:
>  Attr0 Type: 1l
> Attr0 Value X: 1
> Attr0 ulValueLen: 1l
> --
> Attr1 Type: 0l
> Attr1 Value: 1
> Attr1 ulValueLen: 8l
> --
> Attr2 Type: 129l
> Attr2 Value: 318c8130
> Attr2 ulValueLen: 143l
> --
> Attr3 Type L: 130l
> Attr3 Value: e0d0302
> Attr3 ulValueLen: 5l

Here the objects are all standard PKCS #11 objects. You seemed to be
confused about the attribute values. Please look at the PKCS #11 spec
for what those values are. They are all there (note your tool is
printing them as long decimal integers, but they are listed in the spec
as hex values).
> +---
> C_FindObjects with:
> session-handle: 100l
> ulMaxObjectCount: 1l
> +---
> C_FindObjectsFinal
It looks like you found an object and returned it as handle 71l
> +---
> C_GetAttributeValue with:
> session-handle: 100l
> hObject: 71l
> ulCount: 2l
>
> template:
> Attr0 Type X: 1l
You are missing something here, our template should have 2 objects in it




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Longterm crypto support

[Robert Relyea]

On 12/14/2013 06:28 PM, Brian Smith wrote:
> Kurt,
>
> Thanks for your suggestions.
>
> On Sat, Dec 14, 2013 at 12:46 PM, Kurt Roeckx  wrote:
>
>> I think we need to come up with a plan to improve security in the
>> long run.  I think what we would like to see in general is:
>> - Only SHA256 or better (and so TLS 1.2)
>>
> This is gated almost purely on servers actually switching to SHA-2 certs
> and TLS 1.2. See https://bugzilla.mozilla.org/show_bug.cgi?id=942515, which
> is related to this. I think it makes sense to revisit this after we figure
> out exactly what we're doing with SHA-1-based certificates, because it
> doesn't make sense to plan to go "SHA-2 only" until that happens. So, we're
> talking about something after 2017. We (the Mozilla community) could help
> coordinate a push for servers to upgrade, but there's not much actionable
> we can do now, AFAICT, except for advocate for improvements by servers and
> fixing any bugs that impair that switchover.

This can also be done without NSS changes. simply add SHA-2 to the
'don't accept signatures' policy.
>
> - Only 2048 bit public, 128 bit symmetric, 256 bit elliptic, or
This might require NSS changes in SSL/TLS to enforce (well you could
check the cert in the callback, but you wouldn't see any DHE keys that
may be generated.
>>   better.
>>
> Approximately 1.5% of Fx26 full handshakes that use RSA certs use keys
> smaller than 2048 bits. So, enforcing the 2048 bit limit is not going to be
> a simple thing to do for a while, even though we want to do it soon. We can
> enforce the 256 bit limit on ECC now though, because literally everybody
> seems to be using the P-256 curve.
That's already happening implicitly in FF because FF only supports NIST
p256, p384, and p521. (Likewise Microsoft only supports these three
curves as well).
>  (This actually makes me wonder if the
> P-384 support even works, since not a single handshake in Firefox 26 used
> it.)

It does, I use it periodically in my testing (particularly with ECC
tokens, so it's not just NSS against NSS).

bob



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SHA-256 support

[Robert Relyea]

On 11/19/2013 10:40 AM, Wan-Teh Chang wrote:
> Bob's answer is accurate.
>
> Note that CAs are more interested in SHA-2 based signature support
> rather than plain SHA-2 support. So another way to track down the NSS
> version is to look at the CVS history of the secvfy.c file:
>
> http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/security/nss/lib/cryptohi/secvfy.c&rev=HEAD&mark=1.30
>
> The relevant revisions are:
>
> 1.7 nelsonb%netscape.com2002-12-11 22:05 Support SHA256, SHA384, and
> SHA512 hashes in NSS.
>
> 1.14 wtchang%redhat.com2005-08-12 16:50 Bugzilla Bug 296410: enlarge
> the buffer size for message digest so that we can generate and verify
> signatures that use SHA-512.
>
> 1.17 rrelyea%redhat.com2006-02-07 22:14 Bug 320583 Support for
> SHA256/384/512 with ECC signing
>
> So it is safe to say that by mid 2006 (NSS 3.11.1, released on
> 2006-05-05) the support of SHA-2 based signatures in NSS was already
> stable and complete, covering both RSA and ECDSA signatures. 
This would map to*:
  Firefox  2.0.0.1
  Thunderbird 1.5.0.10
  Mozilla 1.9a1
  Seamonkey 1.0.8

> Another
> evidence of mature support is the FIPS 140-2 validation of NSS 3.11.4
> (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#814).
>
> A very conservative response would be NSS 3.11.4
> (http://www-archive.mozilla.org/projects/security/pki/nss/nss-3.11.4/nss-3.11.4-release-notes.html)
> and later.

This yields the same list (it looks like mozilla picked up 3.11.5 as the
first nss 3.11 build it shipped).


* Source, the cvs log for nss.h, the one file known to change for every
release (because it has the NSS version numbers).
>
> Wan-Teh




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SHA-256 support

[Robert Relyea]

On 11/19/2013 02:50 AM, Rob Stradling wrote:
>> On 11/18/2013 07:00 AM, Gervase Markham wrote:
>>> Hi everyone,
>>>
>>> Following Microsoft's announcement re: SHA-1, some CAs are asking
>>> browser and OS vendors about the ubiquity of SHA-256 support. It would
>>> be a help to them if we could say:
>>>
>>> - Which version of NSS first supported SHA-256
>
> Gerv, SHA-256 isn't the only algorithm of interest here.
>
> The latest Windows Root Certificate Program requirements [1] permit
> CAs to use SHA-256, SHA-384 and SHA-512.  Unsurprisingly, these 3
> functions from the SHA-2 family are what the Windows CryptoAPI
> actually supports (since XP SP3).
>


My evaluation on when we supported SHA-2 covers all 3 hash functions.


> On 19/11/13 02:20, Robert Relyea wrote:
>> I think it's safe to say if your NSS ap is newer than a decade old, you
>> have SHA-2 support. The one caveat is that SHA-224 support was added
>> much later, but SHA-256, SHA-384, and SHA-512 have all been supported
>> for a while.
>
> SHA-224 isn't supported by CryptoAPI, and CAs aren't permitted (by
> [1]) to use it anyway.  Ditto for the SHA-512/224, SHA-512/256 and
> SHA-512/t functions that were added to the SHA-2 specification [2]
> last year.

We don't support the "truncated"* SHA-512 functions (other than
SHA-384). SHA-224 is a "truncated"* SHA-256.


* "truncated" hashes also have their own initialization vector, so
SHA-224(x) != trunc(SHA-256(x)) even though SHA-224 uses the same base
algorithm.
>
>
> [1]
> http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx
>
> [2] http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf
>




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SHA-256 support

[Robert Relyea]

On 11/18/2013 07:00 AM, Gervase Markham wrote:
> Hi everyone,
>
> Following Microsoft's announcement re: SHA-1, some CAs are asking
> browser and OS vendors about the ubiquity of SHA-256 support. It would
> be a help to them if we could say:
>
> - Which version of NSS first supported SHA-256
I quick look at the cvs logs shows that it was supported at least by nss
3.7. (There's an NSS_3_7_RTM tag for revision 1.4 for sha512.c, which
has sha512, sha384, and sha256 support).
> - Which versions of Mozilla/Firefox/SeaMonkey/Thunderbird that translates to
The cvs logs include tags for various
Mozilla/Firefox/Thunderbird/Seamonkey releases (the code predates
mozilla's move to hg).

The earliest mozilla release was Mozilla 1.3.
The earliest thunderbird release was 0.2 (essentially every thunderbird
release).
The earliest firefox release was 0.8 (essentially every release of firefox).
The earliest seamonkey was 1.0 (again, essentially every release of
seamonkey).

>
> They can use the NSS version number info to work out the answer for
> other NSS-using applications.
Yes, though the upshot is if your nss-based ap isn't Netscape or AOL
branded, it almost certainly has SHA-2 support. (heck even AOL branded
things like photon has the SHA-2 support).
>
> Is anyone from the NSS team able to easily provide that info? I could go
> repo and Bugzilla-mining, but I'd be worried about making a mistake.

SHA-256/SHA-512 code has been in for a very long time. Nelson checked in
the initial revision around Nov 2002, and the first NSS release (3.7)
was sometime between Nov 2002 and Mar 2003. The change predates the mass
tri-license work done in 2004 (I see gerv's tri-license changes in the
logs).

I think it's safe to say if your NSS ap is newer than a decade old, you
have SHA-2 support. The one caveat is that SHA-224 support was added
much later, but SHA-256, SHA-384, and SHA-512 have all been supported
for a while.
>
> Gerv




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto