Won't work. Basically you describe remote attestation system and for this to work you must trust _all_ other components on system. Let's suppose I'm Evil Hacker who wants to extract SKEY from Good Viewer. (and I don't have my own as developer of Another Good Viewer) Given _current_ situation with code I will simple write simple program which inject Evil.dll into SecondLife.exe process and use Evil.dll to find SKEY. Location of SKEY is know from published sources (In fact even this is not need. Ultinmate pirate tool called Debugger(for example one from MSVS) couldl be more than enough). SecondLife.exe can't protect against such tricks(well, it can try but it will make compatibility problems, there are too much software which do code injection for legitimate purposes. And if SecondLife.exe's protection against this is good enough...well,I'm Evil Hacker, I will just use Evil Kernel of Linux(and SecondLife will still support Linux,right? Good luck validating _kernel_, especially some Linux distributions still _require_ you to build your own kernel). And of course were are even more ways.
But! What could be done easily is making sure that _by_ default unsigned viewer binary don't connect to Main Grid, Sign key can only be got if your account is validated and signature IS displayed. Also, on connect grid responds back via chat (at random interval of 1-10 minutes) to user which viewer was used and who signed it according to what grid see(random interval is make it difficult for Evil Viewer to modify this response) And make removal of this code not VERY easy to defer script kiddies. (but not experienced devs). It's very likely that this will be much better than today. And it protects _users_ agains Evil Viewers Anyway today difference between one of popular viewers which respects permissions and same viewer which doesn't respect them is about 10 lines of code. Yet I never saw 'non-respecting' version of this popular viewer 2009/10/21 Tigro Spottystripes <[email protected]> > what I was thinking was that the viewer binary would somehow be signed > in a way that it could be verified as having been generated by someone > that has been given a trust key from LL, the exactly how part went down > the drain kinda > > Mike Dickson escreveu: > > How does that help validate a viewer is "certified"? I can see a OTP to > > validate a user. The point with the GSM example is the source info is > > "tamper proof." I don't see that here with a viewer, especially an open > > source one where source needs to be distributed. > > > > On Wed, 2009-10-21 at 15:59 +0000, Anders Arnholm wrote: > > > >> No the screat are probalt some muchg lnger than allen, it will be > >> trasforemed with an algoritm. > >> > >> f(SKEY, Challange) > >> > >> Is what are going to be sent, this to make sure that KEY are not sent > >> over the net and intercepter by anyone on the internet. The problem some > >> to the viewer have to be able to make the calculation f(SKEY, Challange) > >> to make this computation the coputer will need to have both the function > >> f(k,c) and the SKEY someware. Whan you have both these to pices of > >> information in one computer figuring out f() and SKEY are a trivial > >> work. > >> > > > > > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- -- Best Regards, Dmitriy Kazimirov,
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
