trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications)
Tim Dierks
tim at dierks.org
Mon Aug 12 13:32:05 PDT 2002
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>
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com
More information about the cypherpunks-legacy
mailing list