Comments on: Client-side Security /blog/client-side-security/ Information Security Think Tank Thu, 21 Aug 2008 20:16:10 +0000 http://wordpress.org/?v=2.6.1 By: Carl /blog/client-side-security/#comment-32496 Carl Thu, 28 Jun 2007 01:42:06 +0000 http://www.gnucitizen.org/blog/client-side-security#comment-32496 I'd sort of forgotten that I'd replied earlier, but here is some more information about how we ensure that the information being served, stored, and manipulated, is as safe as possible. Assumptions: 1 - The client is compromised 2 - The network is compromised 3 - The server may be compromised (If the server is compromised, then all security is out the window, as the attackers can read straight from RAM, or poke around pretty much anywhere). There are a couple of last-ditch measures that can be put in place, but all they will do is cause the system to halt - since it has identified itself as being compromised. As we are only considering the user's experience for this discussion, we need to find a way to ensure that the client is assured that they are interacting with OUR service, and not a MITM. There are a handful of techniques that we have developed that can give the client a high confidence level that they are interacting with the legitimate service. While they can be spoofed in appearance, their functionality can't. I know that this is something that many people say can't be done, but those people are artificially limiting the scope of their imagination. This is a real world problem that had existed and been solved in other fields of speciality for some time. Some of these solutions can be modified to fit InfoSec. Secondly, we need to ensure that an absolute minimum of sensitive data is sent by the client across the network (considering sniffing and replay attacks). We assume that someone can sniff, and has sniffed, the connection and is able to try a replay attack. In this instance it isn't so much the security of the client, but how the server responds to falsified connections. The goal is to neutralise any and all replay / false connection attempts. Intelligent data design, compartmentalisation, and management will limit the amount of sensitive data exposure that is possible. The other component is to ensure that client-supplied data is extremely volatile - once the legitimate client has used that data, it can't be re-used. Now, this is just scratching the surface of what we have done. We know that it is impossible to be completely secure, but we can make it hard enough. As the solutions evolve, we can keep one or two steps ahead of those trying to break them, so it isn't a one-shot one-off solution - it does require continual improvement. Now for the best part - the base theory can be implemented in many different languages and on most platforms (we always develop for a cross platform solution), and it can be a simple wrapper that encapsulates existing apps - enhancing the security (though it isn't as effective as a ground-up solution). The same underlying problems affect online voting and online finance and it was through considering these challenges that we started to develop our solutions (and then spent the last few years breaking and refining them). For more info, you can always email me. I’d sort of forgotten that I’d replied earlier, but here is some more information about how we ensure that the information being served, stored, and manipulated, is as safe as possible.

Assumptions:
1 - The client is compromised
2 - The network is compromised
3 - The server may be compromised (If the server is compromised, then all security is out the window, as the attackers can read straight from RAM, or poke around pretty much anywhere). There are a couple of last-ditch measures that can be put in place, but all they will do is cause the system to halt - since it has identified itself as being compromised.

As we are only considering the user’s experience for this discussion, we need to find a way to ensure that the client is assured that they are interacting with OUR service, and not a MITM.

There are a handful of techniques that we have developed that can give the client a high confidence level that they are interacting with the legitimate service. While they can be spoofed in appearance, their functionality can’t.

I know that this is something that many people say can’t be done, but those people are artificially limiting the scope of their imagination. This is a real world problem that had existed and been solved in other fields of speciality for some time. Some of these solutions can be modified to fit InfoSec.

Secondly, we need to ensure that an absolute minimum of sensitive data is sent by the client across the network (considering sniffing and replay attacks). We assume that someone can sniff, and has sniffed, the connection and is able to try a replay attack. In this instance it isn’t so much the security of the client, but how the server responds to falsified connections. The goal is to neutralise any and all replay / false connection attempts.

Intelligent data design, compartmentalisation, and management will limit the amount of sensitive data exposure that is possible. The other component is to ensure that client-supplied data is extremely volatile - once the legitimate client has used that data, it can’t be re-used.

Now, this is just scratching the surface of what we have done. We know that it is impossible to be completely secure, but we can make it hard enough. As the solutions evolve, we can keep one or two steps ahead of those trying to break them, so it isn’t a one-shot one-off solution - it does require continual improvement.

Now for the best part - the base theory can be implemented in many different languages and on most platforms (we always develop for a cross platform solution), and it can be a simple wrapper that encapsulates existing apps - enhancing the security (though it isn’t as effective as a ground-up solution).

The same underlying problems affect online voting and online finance and it was through considering these challenges that we started to develop our solutions (and then spent the last few years breaking and refining them).

For more info, you can always email me.

]]> By: pdp /blog/client-side-security/#comment-29607 pdp Mon, 18 Jun 2007 08:21:35 +0000 http://www.gnucitizen.org/blog/client-side-security#comment-29607 true, but ... keep in mind that business still needs to make money. you cannot abandon everything and start from scratch. the world does not work this way. we need to find a compromisable way of introducing security while keeping the efficiency and usability intact. true, but … keep in mind that business still needs to make money. you cannot abandon everything and start from scratch. the world does not work this way. we need to find a compromisable way of introducing security while keeping the efficiency and usability intact.

]]> By: Teller /blog/client-side-security/#comment-29376 Teller Sun, 17 Jun 2007 08:24:34 +0000 http://www.gnucitizen.org/blog/client-side-security#comment-29376 Clinet-Side security is underestimated. IMO, there is no real Client-side security unless you use a strong encryption or a well permission mechanism. Client must be designed to be secured just like the server. There are alot of vectors which one can exploit local security, since we own the client and have full access. Vendors should start writing low-level code, put delicate code in read only sections, they should also use encryption and permission mechanism. So there will be more authentication windows, and performance issues, so what? If we look at the big picture, this is for the best. Clinet-Side security is underestimated.

IMO, there is no real Client-side security unless you use a strong encryption or a well permission mechanism. Client must be designed to be secured just like the server.

There are alot of vectors which one can exploit local security, since we own the client and have full access. Vendors should start writing low-level code, put delicate code in read only sections, they should also use encryption and permission mechanism.

So there will be more authentication windows, and performance issues, so what? If we look at the big picture, this is for the best.

]]> By: dpd /blog/client-side-security/#comment-28465 dpd Tue, 12 Jun 2007 11:45:02 +0000 http://www.gnucitizen.org/blog/client-side-security#comment-28465 useless discussions........ it's all relative, u can't never be invulnerable. it's all for money. Security experts...bah... if a person had the capabilities he can break in every (virtual) place... if we consider the physical brute force....we're dead...so ... the point is that security and security experts are totally useless in extreem conditions guys... so this discussions are valid for the 98% of the humanity...but if we count the 2%... this is my point of view...maybe too sadddd ... but for me is reality.. bye'' useless discussions…….. it’s all relative, u can’t never be invulnerable. it’s all for money. Security experts…bah… if a person had the capabilities he can break in every (virtual) place…
if we consider the physical brute force….we’re dead…so …

the point is that security and security experts are totally useless in extreem conditions guys…

so this discussions are valid for the 98% of the humanity…but if we count the 2%…

this is my point of view…maybe too sadddd …
but for me is reality..

bye”

]]> By: pdp /blog/client-side-security/#comment-28449 pdp Tue, 12 Jun 2007 09:05:10 +0000 http://www.gnucitizen.org/blog/client-side-security#comment-28449 Carl, this is very interesting. Of course I am really looking forward to hear how exactly you solved that problem in way that users are still allowed to perform their activities without the overall security of the network being compromised. IMHO, there is no single golden solution for client-size problems, mainly because there are different aspects to be considered. Client-side security problems of Wifi networks are completely different from those found in Web technologies, for example. Carl, this is very interesting. Of course I am really looking forward to hear how exactly you solved that problem in way that users are still allowed to perform their activities without the overall security of the network being compromised.

IMHO, there is no single golden solution for client-size problems, mainly because there are different aspects to be considered. Client-side security problems of Wifi networks are completely different from those found in Web technologies, for example.

]]> By: Carl /blog/client-side-security/#comment-28428 Carl Tue, 12 Jun 2007 03:01:33 +0000 http://www.gnucitizen.org/blog/client-side-security#comment-28428 It might sound a little bit glib, but as far as our development practices go, we ALWAYS consider the client to be compromised, and factor that into how our systems respond to every request from a client. Authentication, smauthentication. Our systems don't even trust the 'authenticated' client, for many of the reasons you listed above. This does make for some interesting problems - how do you design and implement a security system that introduces low overheads without compromising security? Of course, HOW we solved that problem isn't quite ready for publication just yet. It might sound a little bit glib, but as far as our development practices go, we ALWAYS consider the client to be compromised, and factor that into how our systems respond to every request from a client.

Authentication, smauthentication. Our systems don’t even trust the ‘authenticated’ client, for many of the reasons you listed above.

This does make for some interesting problems - how do you design and implement a security system that introduces low overheads without compromising security?

Of course, HOW we solved that problem isn’t quite ready for publication just yet.

]]>