Design proposal: crypto-capable generic interface
Hi to cypherpunks who write code, The recent discussion of "plug-in" crypto is reminding me of some design work I did earlier this year. This post presents the motivation and some of the details of that design, slightly updated. First, a few words about what I consider to be good interface that can support plug-in crypto. It has to support both email and the Web; I feel that everything else follows. It should support completely transparent integration, by which I mean no extra clicking or commands or anything like that. Finally, it should be generic in that it will support a number of other plug-in applications besides cryptography. Two specific applications which interest me are file format conversions and external-body resolving. The design is based partly upon .mailcap, which is perhaps the best example of a generic interface we have today. However, while .mailcap is a nice interface for popping up windows to present semi-interesting multimedia types, it certainly cannot support transparent cryptography. I feel that its primary weakness is the inability to support MIME to MIME rewriting. However, .mailcap has some good ideas which are worth stealing. For the purposes of this proposal, I will assume that all objects are MIME encapsulated. I think that's a reasonable assumption, as it handily covers all cryptographic protocols that have any hope of surviving. I will propose my design at a very high level. Please forgive me for leaving out the juicy details. I propose that the new interface lives as a sort of daemon, rather than a static collection of command line script pieces. A reasonable way for applications to talk to the daemon would be Unix domain sockets, or whatever the equivalent is on Mac and Windows platforms. There should be a simple protocol for automatically starting up a daemon if there isn't one already running. The first part of the interface is the negotiation. The daemon tells the application what MIME types it can understand (this part is very similar to the .mailcap file, but doesn't include the corresponding command lines). In reply, the application tells the daemon what MIME types it can understand (this is like the Http-Accept: field in HTTP). Once the negotation has been established, the application can send the daemon MIME objects that the app does not understand but the daemon does (for example, an image/fractal). The daemon can return a MIME object that the app does understand (for example, an image/ppm). Alternatively, the daemon may request an authentication. This is useful when resolving external bodies that require authentication, including non-anonymous FTP, and standard authenticated HTTP. In this case, the daemon sends a message to the app requesting the authentication. It specifies whether it needs both username and password, or just password. In the latter case, it hands a username to the application. The application can then query the user for the authentication data. It hands this back to the daemon. In reply, the daemon indicates success or failure. In case of success, it hands the object back to the app. I'm quite pleased with this protocol as outlined. It's fairly simple, which means it might actually get implemented. It's also easy to see that it does exactly what you want for file format conversions, external body resolving, and decryption of encrypted messages. Encryption is a bit more tricky, but in essence you just hang a premail-alike off this kind of protocol. The hard part is specifying the key, but you just call it a "parameter" and put in hooks for the daemon to ask for whatever parameters it needs. This requires that keys have some nonforgeable names, which is unfortunately not a feature of PGP 2.6.2. S/MIME will do it just fine, if you buy into the Certifcation Authority (<wink> at Nick Szabo). One final aside: I've been fairly frustrated with this mailing list as a forum for talking about real design proposals and implementation issues. Ignorant posts by the likes of Dr. Fred and Alice d'Clueless tend to attract far more attention than real crypto work. I want a forum for, and just for, cypherpunks who write code. If I had just a smidgen more free time (as if), I'd be trying to start one myself. Anyone else? Raph
Raph Levien wrote: | I propose that the new interface lives as a sort of daemon, rather | than a static collection of command line script pieces. A reasonable | way for applications to talk to the daemon would be Unix domain | sockets, or whatever the equivalent is on Mac and Windows | platforms. There should be a simple protocol for automatically | starting up a daemon if there isn't one already running. A daemon per user, or per machine? Either way, I think you run into problems on a big multi-user machine. (Either its an extra process or two per person, or its a great target for attack & subversion. Its an interesting proposal, but let me ask you this--Why is it better than a libpgp (or pgp.dll) that offers a variety of services to programs at multiple levels (ie, offers full one call RSA/IDEA encryption and compression, as well as ascii armoring, or offers each of those as a seperate function. -- "It is seldom that liberty of any kind is lost all at once." -Hume
On Sat, 18 Nov 1995, Adam Shostack wrote:
Raph Levien wrote:
| I propose that the new interface lives as a sort of daemon, rather [snip] |
A daemon per user, or per machine? Either way, I think you run into problems on a big multi-user machine. (Either its an extra process or two per person, or its a great target for attack & subversion.
_anything_ that has open access on a piece of hardware is a point of intrustion --sendmail for instance, or open password files, etc. the issue is trading off risks to _maximize_ security and impenatrable access. even assuming we were to post 100% of the source code, a translation daemon is a _translation_ model --even if it is capable of translating pgp, garbage in equals nothing out... one of the biggest problems with _any_ crypto system, and pgp is no exception, is tmp files, followed closely by insecure memory. insecure memory is a separate issue, but some of the temporary file problems can be relegated to reduced risk by passing the daemon the user's preferred location for tmp file --for instance, on any net access machine, I globally specify TMP, TEMP, etc to a local tmp directory which is at least somewhat safer than public tmp files. obviously, you expect the daemon to wipe clean each memory block before it free()s it --I's sure we all have routines handy for that. presuming the daemon is constructed so it can only respond to its current process owner, this leaves the security problem of swapping in a daemon which also responds to an interloper --and this same risk applies to a libppg or a .dll file (more so to a .dll file) to an even greater degree. However, if a daemon is swapped, the system has a more _serious_ problem with the system administrator, not the daemon. if the IPC strings are intercepted in the daemon initializtion, again we have a basic hardware and system security problem. Even If Ralph Levian believes daemons are serious risk problems (which they can be if not properly implemented), I do not agree that the libppg() or .dll offer anything additional. I dont presume to believe that anything is safe anyway, just safer than the alter- native. NB: _nothing_ should ever be assumed secure! assumption is fuckup's mother. one must hope to have considered every possible line of attack, and a few which have not been conceived, which goes back to our cypherpunk "credo" which says that private standards are not safe --let's all have at it --even if we break it, there probably is a way to block the attack, we just did not block it or consider it the first time, I have been playing with all three approaches, and I keep going back to the daemon despite the fact it is not portable to the brain dead. I don't know if W95 permits daemons as I have ignored MS for a number of years --if I can not run as many processes as I want without some MickeySoft program blowing away a day's work.... I prsume NT will run 'em, and maybe the next release of NT will be more useable, more secure, and more stable. Since pgp() has been pulled from crypto10, I need to modularize pgp to a pgp() and include the relevant goodies such as MIME and its variations. And, of course, we need all the "we do it here" types to buy into a standard interface. And, to add fuel: the module needs the ability to encode and place clear text into a MIME format specified by the calling program.
Its an interesting proposal, but let me ask you this--Why is it better than a libpgp (or pgp.dll) that offers a variety of services to programs at multiple levels (ie, offers full one call RSA/IDEA encryption and compression, as well as ascii armoring, or offers each of those as a seperate function.
not necessarily better. but a valid approach IMHO. I for one think it would be easy enough to sell IAPs on a daemon.
-- "It is seldom that liberty of any kind is lost all at once." -Hume
atilla brings up many good points, including:
one of the biggest problems with _any_ crypto system, and pgp is no exception, is tmp files, followed closely by insecure memory. insecure memory is a separate issue, but some of the temporary file problems can be relegated to reduced risk by passing the daemon the user's preferred location for tmp file --for instance, [...]
An even better solution is to design the cryptosystem so that it doesn't _need_ temp files int he first place. MOSS wins, PGP loses. I don't know enough about S/MIME to say. In a related vein, Darren New <dnew@sgf.fv.com> sent me a pointer to First Virtual's SMXP (Simple Mime eXchange Protocol). This is a cool protocol that does about 50% of what I'm talking about. If you're interested, here it is: ftp://ftp.fv.com/pub/docs/smxp-spec.{ps,txt} In order to adapt SMXP into something that's useful for what I've proposed, numerous changes would need to be made: * Unix Domain Sockets instead of TCP * Add negotiation * Add authentication Without these three changes, the system is nearly useless for crypto. Further, there are two "aesthetic" points I'd like to see claned up given the chance. First, SMXP makes the "ASCII assumption." Since the daemon and app will be tightly coupled, definitely running on the same machine, there is no reason to exclude binary MIME objects. On the other hand, as far as I know, all of the MIME crypto protocols are ASCII based (somebody please correct me if S/MIME is the exception). Second, in order to support operation without temp files, it's necessary to interleave the operations of transferring the object from the app to the daemon and vice versa. I have a proposal for a lower-level spec which can handle this quite readily, if anyone is interested. Unfortunately, the proposal doesn't look much like SMXP. However, the possibility of creating a prototype based on SMXP is intriguing. Raph P.S. Did anyone see the mention of the perl/RSA CJR in the latest Wired? Managed to get the attribution wrong. Still no response.
s1113645@tesla.cc.uottawa.ca wrote:
MOSS?
MIME Object Security Services. It's a technically superior alternative to PGP, but one with an uncertain future. It's not being actively developed by anyone other than TIS, and their TISMOSS prototype implementation is far from being generally usable. For more information on the standard, see RFC 1848: http://ds.internic.net/rfc/rfc1848.txt For more information on the TIS effort, see: http://www.tis.com/docs/Research/moss.html Raph
MIME Object Security Services. It's a technically superior alternative to PGP, but one with an uncertain future. It's not being actively developed by anyone other than TIS, and their TISMOSS prototype implementation is far from being generally usable.
What do you mean by "technically superior"? What technical merits does MOSS have over PGP? It does have a better protocol with which to integrate it into mailers, but it is only a transmission protocol, not a security mechanism change. Worse, MOSS uses X.509, which requires a lot of overhead for certificates. On the other hand, the MIME-PGP protocol can provide the same integration functionality as MOSS and still allow the use of the simple PGP certification structure that already exists. -derek
On Sun, 19 Nov 1995, Derek Atkins wrote:
What do you mean by "technically superior"? What technical merits does MOSS have over PGP? It does have a better protocol with which to integrate it into mailers, but it is only a transmission protocol, not a security mechanism change. Worse, MOSS uses X.509, which requires a lot of overhead for certificates.
Ah, I was hoping that my statement would stir some controversy. I've learned that well thought out, carefully reasoned posts never get any response. I agree with you that the X.509 stuff is extra baggage in MOSS. Fortunately, the use of X.509 is optional. MOSS has two very large advantages over PGP: 1. It can operate without temp files. 2. It has no non-MIME variant. It will take forever for PGP/MIME to catch on. Thus, PGP will never really be a suitable candidate for my generic interface. Ah well.
On the other hand, the MIME-PGP protocol can provide the same integration functionality as MOSS and still allow the use of the simple PGP certification structure that already exists.
This is true. I hope it happens.
-derek
Raph
Adam Shostack wrote:
A daemon per user, or per machine? Either way, I think you run into problems on a big multi-user machine. (Either its an extra process or two per person, or its a great target for attack & subversion.
One per user. I'm thinking that, most of the time, the daemon process would only last as long as the application. It is certainly true that if there were to be one daemon per machine, the security requirements would be a lot greater, as it would no longer be possible to rely on the operating system to get the file permissions right, etc. On the other hand, the daemon process better be done right, or your're in trouble anyway.
Its an interesting proposal, but let me ask you this--Why is it better than a libpgp (or pgp.dll) that offers a variety of services to programs at multiple levels (ie, offers full one call RSA/IDEA encryption and compression, as well as ascii armoring, or offers each of those as a seperate function.
Exportability. There is a general feeling that a mailer program with specific hooks to libpgp is going to have trouble with exportablity (and forget about binaries), where a program that supports a generic interface (the likes of .mailcap) is out of the NSA's jurisdiction. Of course, this is speculation until we actually get a ruling, but it sounds plausible enough to me to warrant spending some time on design and implementation. Your question brings up another point: if the daemon process is going to run as the personal slave of the application, then why not a dynamic library instead? Two reasons. First, on Unix anyway, interprocess communication through domain sockets is a more mature, robust, and portable technology than dynamically linked libraries. On Windows, it's probably the other way around, and that's worth thinking about. The real reason is, though, that the daemon and application should naturally be distrustful of each other's address spaces. Can you see Netscape shipping code that links in a Joe Random dll? Conversely, do you want your PGP secret data structures sharing an address space with one of Netscape's beta releases? Using two processes in two address spaces solves this problem. Jeff, if you're reading this, what do you think Netscape's chances are for supporting such a protocol, assuming of course that there were nicely implemented daemons, and that the protocol itself was going to standards track? Is it something you'd be interested in? Raph
On Sat, 18 Nov 1995, Adam Shostack wrote:
A daemon per user, or per machine? Either way, I think you run into problems on a big multi-user machine. (Either its an extra process or two per person, or its a great target for attack & subversion.
Not any more are target for attack than a shared library. Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
participants (6)
-
Adam Shostack -
Aleph One -
attila -
Derek Atkins -
Raph Levien -
s1113645＠tesla.cc.uottawa.ca