That’s you hosting the service on somebody else’s server. I meant somebody else hosting the service, which means somebody else running the software and having admin rights, and there’s no way you’re securing that.
Just almost no one bothers to take the time
Obviously. Imagine if we applied the same logic to food safety, or anything else. There’s no practical way to be self-sufficient in all aspects, and no reason we should be.
Not really, okay I am going to give you the back of the napkin black box operation.
So you lease the instance and spin it up from the console. The first thing you do is set up a SSH key only access instance so from the moment its spun up, the only logins will be from a key that the hosting service is not privy to.
Once established and you make a shell connection, you can SEE how many logins there are and there will be only you. Ok then you set up a virtual machine within that system that maps to the NIC of the host.
Now you have a virtual machine inside a virtual machine that the host service has no access to.
that second virtual machine’s secure shell login is set to a non-rotating one time pad that is delivered while monitoring virtual machine 1 for alternate logins. If at any time it is suspected, the entire instance can be wiped and the one time pads discarded and a new pair generated and the process begun again
Once the nested virtual machine is operating, its memory operations are also encrypted by the one time pad, provided it was uploaded completely within the window where you were the only logged in user to VM 1, this means even with the most sophisticated memory reading technology, without that one time pad the data is unreadable, and the only way to get the pad is to have been watching while the pad was uploaded to the 2nd virtual machine.
In this scenario since we have maintained theoretically perfect end to end encryption thrice over, so the one time pad doesn’t need to be large, because when you get to the end of the shared key list the last record can be used to safely transmit another arbitrarily large one time pad.
The ONLY way this scenario is compromised is:
A compromised kernel and since we are being careful with our distros, we know it is valid and tested by millions of man hours, this is unlikely
Someone using a quantum computer to crack the public key set used to secure the 2nd virtual machine via direct reading of the physical server’s memory, jumping in as an invisible Man in the Middle attack in the time between the 2nd instance is spun up and the first one time pad record is received (we are talking fractions of a second)
And EVEN THEN they just have the digits of the one time pad don’t contain their method, that’s in the 2nd VMs kernel and is unreadable in memory unless you can guess the method perfectly the first time.
Let me give you an example, this is ridiculously simplified:
say the one time pad first entry is:
5TF7M828D3
and the method is ‘add the hex value of every 3rd character and xor it with the hex value of every 2nd character’, and that is the base encoding for the private key that will be secure
See?
you can be aware of the string: 5TF7M828D3, but not know how to manipulate it to get the desired secure private key
I understand the scenario you are describing to me, and that it’s perfectly plausible. (I do see a potential weakness or two which I’d love to discuss separately). Let me try to clear up the confusion in the current discussion thread. What you are describing is somebody running their own software service. This is possible, I’m not arguing that. My original assertion, is that if you allow somebody else to run the SOFTWARE service for you, you are inherently at their mercy. Based on what you’ve just described, I’m absolutely certain you agree with that assertion. This is also the only reasonable way most of the world would have access to most online services. The idea of everybody hosting their own software stack for every service they would like to use is laughably impractical and implausible.
I think what you are trying to say is that if they have shell access it is insecure and yes I agree with that
But even if they have shell access, as long as I can be assured no one else is logged in, I can make any linux box just as secure in about twelve minutes using the above scenario.
Yes in what I described there are weaknesses such as L1 cache doping to vastly reduce uncertainty making identification of prime stripes in packets trivial, but to practically pull that off you need an electron microscope installed above a naked operating processor meaning the entire room has to be sub zero and sealed from contaminants and prepared days beforehand
Which means that any joe schmo spinning up a digitalocean droplet isn’t going to be hosted on a machine with NSA grade top level memory and CPU observation installed
I was more thinking that, in theory, anything you install and run could be compromised from the get go. With enough prep, any distro could be replaced with a compromised version on the fly and you would have no way to tell. Any tools you use could similarly be compromised to give you untrustworthy output. It would require a heck of a lot of investment, but not beyond the scale of nation states, and would be pretty scalable.
That’s you hosting the service on somebody else’s server. I meant somebody else hosting the service, which means somebody else running the software and having admin rights, and there’s no way you’re securing that.
Obviously. Imagine if we applied the same logic to food safety, or anything else. There’s no practical way to be self-sufficient in all aspects, and no reason we should be.
Not really, okay I am going to give you the back of the napkin black box operation.
So you lease the instance and spin it up from the console. The first thing you do is set up a SSH key only access instance so from the moment its spun up, the only logins will be from a key that the hosting service is not privy to.
Once established and you make a shell connection, you can SEE how many logins there are and there will be only you. Ok then you set up a virtual machine within that system that maps to the NIC of the host.
Now you have a virtual machine inside a virtual machine that the host service has no access to.
that second virtual machine’s secure shell login is set to a non-rotating one time pad that is delivered while monitoring virtual machine 1 for alternate logins. If at any time it is suspected, the entire instance can be wiped and the one time pads discarded and a new pair generated and the process begun again
Once the nested virtual machine is operating, its memory operations are also encrypted by the one time pad, provided it was uploaded completely within the window where you were the only logged in user to VM 1, this means even with the most sophisticated memory reading technology, without that one time pad the data is unreadable, and the only way to get the pad is to have been watching while the pad was uploaded to the 2nd virtual machine.
In this scenario since we have maintained theoretically perfect end to end encryption thrice over, so the one time pad doesn’t need to be large, because when you get to the end of the shared key list the last record can be used to safely transmit another arbitrarily large one time pad.
The ONLY way this scenario is compromised is:
A compromised kernel and since we are being careful with our distros, we know it is valid and tested by millions of man hours, this is unlikely
Someone using a quantum computer to crack the public key set used to secure the 2nd virtual machine via direct reading of the physical server’s memory, jumping in as an invisible Man in the Middle attack in the time between the 2nd instance is spun up and the first one time pad record is received (we are talking fractions of a second)
And EVEN THEN they just have the digits of the one time pad don’t contain their method, that’s in the 2nd VMs kernel and is unreadable in memory unless you can guess the method perfectly the first time.
Let me give you an example, this is ridiculously simplified:
say the one time pad first entry is:
5TF7M828D3
and the method is ‘add the hex value of every 3rd character and xor it with the hex value of every 2nd character’, and that is the base encoding for the private key that will be secure
See?
you can be aware of the string: 5TF7M828D3, but not know how to manipulate it to get the desired secure private key
I understand the scenario you are describing to me, and that it’s perfectly plausible. (I do see a potential weakness or two which I’d love to discuss separately). Let me try to clear up the confusion in the current discussion thread. What you are describing is somebody running their own software service. This is possible, I’m not arguing that. My original assertion, is that if you allow somebody else to run the SOFTWARE service for you, you are inherently at their mercy. Based on what you’ve just described, I’m absolutely certain you agree with that assertion. This is also the only reasonable way most of the world would have access to most online services. The idea of everybody hosting their own software stack for every service they would like to use is laughably impractical and implausible.
I think what you are trying to say is that if they have shell access it is insecure and yes I agree with that
But even if they have shell access, as long as I can be assured no one else is logged in, I can make any linux box just as secure in about twelve minutes using the above scenario.
Yes in what I described there are weaknesses such as L1 cache doping to vastly reduce uncertainty making identification of prime stripes in packets trivial, but to practically pull that off you need an electron microscope installed above a naked operating processor meaning the entire room has to be sub zero and sealed from contaminants and prepared days beforehand
Which means that any joe schmo spinning up a digitalocean droplet isn’t going to be hosted on a machine with NSA grade top level memory and CPU observation installed
I was more thinking that, in theory, anything you install and run could be compromised from the get go. With enough prep, any distro could be replaced with a compromised version on the fly and you would have no way to tell. Any tools you use could similarly be compromised to give you untrustworthy output. It would require a heck of a lot of investment, but not beyond the scale of nation states, and would be pretty scalable.