Hello again
On 11/08/2009 10:32 AM, Marc Kaeser wrote:
Hello Robert,
where can I get in touch with the NSS people you told me about? I want
to try to do those modifications.
I'm one of them:).
Cool!!! Do you want to become my project manager? Please :-D
It's magic that knows the structure of the softoken. For what you want,
you don't need any of this. Simply store the SDR token name in the prefs
and use PK11_GetSlotByName() {warning I often give function spellings by
memory, so the actual function spelling may be different, you'll have to
look in the header file}. You'll want to change nsSDR rather than trying
to convince NSS to present your token as the default internal token (the
latter could cause you more pain than it's worth).
That sounds easy enough for me to understand ^^ Soon or late, I'm going to
be able to find out how. I don't know all the functions that internal token
is used for, by now. I've been trying to find that internal token and its
keys to understand how the whole structure works.
[ your explanation about FIPS ]
I read something about FIPS on the Mozilla pages. If I understand that thing
correctly, it has something to do with US-american governement
data-security-policy, which tells that you mustn't use software without
encrypting everything you do with your software. So if you want that
governement accept that the users use your software, it has to be FIPS
compliant. That's the reason why FIPS-mode exists, isn't it?
NOTE: Even though I explained this, it's important not to try to
simulate either of these functions. In the latest version of NSS we've
made some changes so the NSS could choose a completely different
softoken module as the internal Keyslot.
I'd like to approximatively know that "magic" you told me about, in order to
understand where the tokens and their keys are stored. I think it must be a
file or a db or something in the user's private directories, or how is
multi-user softoken-management implemented?
I think in the case of a token that comes from a device that I plug in, it's
going to be one single token/key. That should be easier.
In general, when you see PK11_GetInternalKeySlot() called, the
application is explicitly saying it is only supporting the internal
softoken for operation. In general, such places are candidates for
changing to something more generic. This is definately one of those
candidates.
Great, let's do it ^^
I'm presuming you mean the PSM entry point.
Sorry, I don't know what you mean by "PSM's entry point". In my idea, NSS is
an XPCOM Service-Component that manages modules->slots->tokens->keys and
different cryptographic algorithms/mechanisms (or how they're called) to do
lots of different cryptographic things. The functionality that interests me
is that SDR-interface, better its implementation, which is used by
mozstorage. For me, the entry point is that interface. But maybe you mean an
init-function or something that builds those module-slot-etc... structures
when NSS is loaded into memory when, in my case, Firefox is loaded.
I guess PSM "just" uses those framework-NSS-functionalities.
By the way, which are the interfaces which use nssdr, I don't think only
mozStorage does.
1. Starting point:
The problem with nsSDR is that you can't choose another slot/token
than the internal one if one wants to use another storage location for
his/her encryption keys. nsSDR.cpp uses PK11_GetInternalKeySlot() at
line 149 without the possiblity to choose.
I presume that's needed to authenticate. I seems to me that it should
get the default SDR token as a pref (probably stored as token name).
nsSDR would need the PK11SlotInfo for this token, not only to
authenticate, but also to pass to the new NSS SDR interface.
That's a point I can't find out. I haven't been able to find out where the
token comes from.
I've just looked at PK11SDR_Encrypt() in pk11sdr, which is called by NSSDR.
Arguments passed to PK11SDR_Encrypt: An initialized keyid mem address, an
initialized data-Secitem (the data that should be encrypted I guess) mem
address, and the mem address where the futurely encrypted "output" should be
written, and a context-object I still have to understand what it is.
(Definition: PK11SDR_Encrypt(SECItem *keyid, SECItem *data, SECItem *result,
void *cx)).
pk11sdr's PK11SDR_Encrypt() is very interesting for me. Again, an
authentication is done for the internalkeyslot, the 3DES mechanism is set,
and the key is returned by PK11_FindFixedKey(slot, type, pKeyID, cx); and...
I'll have to read more precisely, it gets complexer, pKeyID is interesting..
it looks like it takes one keyID per default (probably the key ID of the
internal softtoken, somewhere...).
In pk11sdr.ch its defined as
static unsigned char keyID[] = {
0xF8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01
};
2. A good solution:
I could modify nsSDR in order to be able to "browse" between all
available "PK11SlotInfo" and "NSSToken" objects, and have e.g. a GUI
to ask the user which slot / token he or her wants to use, or use the
cryptography-module-manager-window to mark the one that should be used
by default. (I have no clue how window-classes are to be implemented
in XPCOM at this point)
You probably want to set this in the preferences. You probably do not
want to try to grab it on the fly just before you encrypt a password.
If I can find out how that works, that would probably be the best idea. But
i don't know where to start to find out how the preferences interact with
the code. I don't even know where they're handled. I "landed" into PSM / NSS
coming from mozStorage. I followed the sourcecode till I reached NSS, to
find out where the encryption key for the mozStorage SQLite DB is hidden.
For the moment, I just have an Idea how modules, slots, tokens, keys are
linked together, or better: Their representations in NSS. And thanks to you
and the people who answered, I think i can imagine that "magic" you talked
about. I guess it must be some variables defined somewhere in the NSS
instance/component/service whatever.
The trick here is when do you need to authenticate to a given token. One
strategy is to always use the token defined in the prefs first. If you
can't find the appropriate key, then you can move to searching other
tokens for the key (a generic PK11SDR_Decrypt that works with all keys).
If you found you had to fall back to another key you can also reencrypt
with your chosen default token.
Sounds great. Try the token in the prefs, if that doesn't work, scan for all
present tokens, make a list (maybe it would be faster to try out after each
found token instead of making a list. But well, there are usually no
millions of tokens I guess) (I also think there are already
token-list-structs somewhere in the libs. If I'm lucky there's even already
a function that does build such a list...), try to find the key in one token
after the other (or efficienter algorithm), and if I can find the key,
decrypt, end reencrypt with the standard pref token key...
The code where you set the default token could also optionally walk
through and reencrypt all the existing keys to your new default token.
This will make the fall back if you can't find the appropriate key less
of a necessity.
Yes maybe it would be a good idea to let the user choose if he/her wants to
reencrypt the data or not. But there's a point I don't understand: At the
moment, I thought the encryption key (in SDR, used for mozStorage) is stored
inside a token. But the way you write, it seems like those keys are stored
somewhere else, and the encryption key to those keys is stored inside a
token. I don't understand why, but i guess both solutions could work, so I
don't know which idea is the right one. I'll surely find out by reading more
of the sourcecode.
Please tell me, if I understand the problem correctly, why isn't that
functionality not already implemented? I asked to myself, NSS is a
complexe and relatively old component I guess, why did nobody do that
already? Someone who is used to XPCOM/NSS could do that in a few...
well... minutes? And I'm going to need... weeks :-D
It's always been "something we could conceivably do in the future". This
stuff tends to grow organically as people need stuff. We try to
architect things so that it hopefully will work in the future (like the
idea of even having a key id).
Now that I need that, it's a great opportunity to let that organic body grow
a little bit :-D I'm a newbie, but given enough time to understand that
PSM-part of the body, I guess I should be able to play surgeon
bob
Marc
"Robert Relyea" <rrel...@redhat.com> schrieb im Newsbeitrag
news:mailman.722.1257806587.526.dev-tech-cry...@lists.mozilla.org...
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
