On Fri, Oct 23, 2009 at 5:13 AM, Abhiram Kasina <abhiram.casina@gmail.com> wrote:
Hi all
Thank you very much for the response. I have tried to answer all the issues as much as I can.
Hm... Given that most infections these days are JavaScript based and run in the browser, how does this provide any protection? I'm presuming you're going to say that it doesn't but that there are other use cases where it *does* provide protection; but most likely those use cases are only relevant for Windows (since that's what most attackers attack anyway).
Guido, I don't know the exact security model and I am currently going through it. But it has a mechanism in which none of the passwords or anything can be ever given out. So, phishing and pharming could be fought better. I agree that most of the cases of viruses are in Windows, but there are many cases in the past in which they have affected linux machines as well. So, if security is being made better, it should be used.
This is dangerously incorrect. Password storage *is* a feature of TPMs, but does no good against network-based attacks, since it cannot (obviously) replace legacy systems for which a normal transmit-and-verify system is used for authentication.
Since this intefaces with the hardware, doesn't it require some kind of cooperation from the Linux kernel? And wouldn't it be better if Python was never allowed access to any of the protected resources in the first place?
There would be a wrapper on top of the drivers running at the kernel level. Lets say there is a Python application which uses some sort of password authentication. If the password is present somehow in the memory, it could be stolen. But if its present inside a completely separate hardware, which doesn't allow it to be retrieved, I think that will be better.
My understanding is that this would require very tight integration with each of the Python implementations as a result of the fact that Python stores data on an internal heap. I may be wrong, IANAE.
Where/what is Umit? (Google gives several meanings but it's unclear which you might mean.)
By Umit, I meant Umit Project [1]. Its the GUI for nmap and its being built completely in Python.
You'd first have to tell us more about the security model. What is a "secure application" and what does it protect against? And how?
Yes, I will take some time to understand the model and present you the details of the model well when I get some time.
I personally have grave concerns about this technology, independent of who is advancing it- just reading the links you provide makes it clear that its primary purpose is to restrict the degree of control a user can exercise over their own data, programs, and machine. Is it any wonder that the same people who find DRM abhorrent find the technologies used to advance it equally distasteful?
Geremy, I have read the TPM specifications to some extent and the only thing enabling DRM here is the presence of a system-specific key. And it is heavily impractical to encrypt every music file with that key, when the vendor is selling it. It could be done even now, they want to do it.
Honestly, this statement boggles me. 1) DRM doesn't work that way, and 2) if you believe that remote attestation does not imply DRM then I simply have nothing more to say here.
If you were suggesting adding a crypto API to python, I'd be all for it- but you're suggesting adding the ability to have Python software vendors remotely cripple the code on your machine. I just can't get behind that, and while you're sure to hear wildly divergent opinions on this board, I suspect that mine will not be an uncommon sentiment.
I appreciate the opinion and I am not suggesting adding a crypto API.
You seem to have missed a few pages in the specification- but no matter. You can get an overview of the cryptography API in sections 4.3.4 and 5.8.2.7 of the TSS 1.2 specification document. It describes the API calls needed to get random data, sign and verify messages, perform cryptographic hashes, and, of course, to encrypt and decrypt data. Geremy Condra