At 09:07 PM 8/12/2002 +0100, Adam Back wrote: >At some level there has to be a trade-off between what you put in >trusted agent space and what becomes application code. If you put the >whole application in trusted agent space, while then all it's >application logic is fully protected, the danger will be that you have >added too much code to reasonably audit, so people will be able to >gain access to that trusted agent via buffer overflow.
I agree; I think the system as you describe it could work and would be secure, if correctly executed. However, I think it is infeasible to generally implement commercially viable software, especially in the consumer market, that will be secure under this model. Either the functionality will be too restricted to be accepted by the market, or there will be a set of software flaws that allow the system to be penetrated. The challenge is to put all of the functionality which has access to content inside of a secure perimeter, while keeping the perimeter secure from any data leakage or privilege escalation. The perimeter must be very secure and well-understood from a security standpoint; for example, it seems implausible to me that any substantial portion of the Win32 API could be used from within the perimeter; thus, all user interface aspects of the application must be run through a complete security analysis with the presumption that everything outside of the perimeter is compromised and cannot be trusted. This includes all APIs & data. I think we all know how difficult it is, even for security professionals, to produce correct systems that enforce any non-trivial set of security permissions. This is true even when the items to be protected and the software functionality are very simple and straightforward (such as key management systems). I think it entirely implausible that software developed by multimedia software engineers, managing large quantities of data in a multi-operation, multi-vendor environment, will be able to deliver a secure environment. This is even more true when the attacker (the consumer) has control over the hardware & software environment. If a security bug is found & patched, the end user has no direct incentive to upgrade their installation; in fact, the most concerning end users (e.g., pirates) have every incentive to seek out and maintain installations with security faults. While a content or transaction server could refuse to conduct transactions with a user who has not upgraded their software, such a requirement can only increase the friction of commerce, a price that vendors & consumers might be quite unwilling to pay. I'm sure that the whole system is secure in theory, but I believe that it cannot be securely implemented in practice and that the implied constraints on use & usability will be unpalatable to consumers and vendors. - Tim PS - I'm looking for a job in or near New York City. See my resume at <http://www.dierks.org/tim/resume.html>
