One of the things about the Cryptographic Services is that it will absolutely refuse to allow access to a private key without an affirmative response from the user, and (optionally) a password -- which window is put on the desktop. It also runs as a different user, so it's (generally, not including people who have the Debug privilege or Administrators) very resistant to tampering.
On SELinux, however, even that threat can be minimized by putting the actual signing app into its own segregated-and-not-ptraceable-or-debuggable object class. In that case, all that would be needed is for /etc/services to be modified (or %systemroot%\system32\drivers\etc\services on Windows) to include the (random) port number assigned to the service at installation time, and then just make a connection to http://127.0.0.1:signerapp/ or something. (presuming Firefox does a getservicebyname() call on the port parameter...) Either way, the document-to-be-signed can be presented to the user through out-of-band means, for verification. (on X, just make it a client with an MIT-SHARED-COOKIE or such.) just some thoughts. :) -Kyle H On 2/14/06, Anders Rundgren <[EMAIL PROTECTED]> wrote: > I have not seen this in real life but apart from the security issues, > I believe this concept has usability problem as the crypto service is > likely to be the viewer as well. At least this is how it has been done > in Austria. > > They are BTW indeed using 127.0.0.1 and some strange port. > > Assuming that the PC (or similar) has reasonable integrity, > I don't see much problems using a native browser plugin. If > the PC is full of viruses and spyware, it is not only useless for > signatures but for any kind of work. > > I also firmly believe that authentication is a much more critical > application as there is no way you can rollback these. > If I insert my eID card in a PC and perform an authentication, > a keyboard logger and spyware daemon may from that moment > authenticate in the background to different services, stealing > information that may be my own or my organization's. Here I > remain optimistic because we will soon have TPM-enhanced > mobile devices that can thwart this situation in several ways like > never doing a auth/sign op without going trough a GUI as well > as allowing particularly sensitive operations to be performed > in the mobile device environment only. Although a pipe-dream > back in 1998 when I started to look into this, now it is actually > happening :-) > > Anders > > ----- Original Message ----- > From: "Kyle Hamilton" <[EMAIL PROTECTED]> > To: "Anders Rundgren" <[EMAIL PROTECTED]> > Cc: <mozilla-crypto@mozilla.org> > Sent: Tuesday, February 14, 2006 08:23 > Subject: Re: Italy: Yet another OpenSignature standards effort > > > This could easily be built into the Cryptographic Services service or > something -- if it's code that comes from the vendor, it's easier to > trust than code that doesn't. > > The problem is the addition of another attack vector, and having to > authenticate to it (unless the process can look at the TCP connection > list and see what process opened it, then get the credentials of that > process to see who it's supposed to impersonate). This could be > mitigated by having it only listen on 127.0.0.1 on some strange port, > but it's still not that great. > > I would rather have another virtual machine entirely running on the > same hardware, but that's something of a pipe dream. > > -Kyle H > > On 2/13/06, Anders Rundgren <[EMAIL PROTECTED]> wrote: > > http://opensignature.sourceforge.net/english.php > > > > These guys have concluded that Java applets are bad and that you > > should exclude the browser altogether by using something called > > URL Programming Interface, which in essens hosts a local web-server > > for handling the crypto and signature stuff. > > > > I believe this is similar to the Austrian scheme, although a bit less > > documented. > > > > Personally I think Java is good as a short-term solution but useless in > > the long-run as Microsoft would never support a Java-based standard. > > The need for accepting native and trusted code during browsing is also > > something that does not seem to be ideal. > > > > Anders R > > > > _______________________________________________ > > 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 > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
