[Opensim-dev] Signing content to prevent malicous creator spoofing was "Re: Global identifiers"

Fri Sep 3 01:13:05 UTC 2010

hey robert,

thanks for forking the new thread, my eyes were beginning to glaze
over as the conversation drifted away from the original topic.

just thought i would chime in with a few points.

first off, the act of signing should be interpreted as the
demonstration of an existing trust relationship; it's important we
understand that. verifying the signature on a blob of data is no
better than verifying the blob's hash UNLESS you ascribe some level of
trust to the key that was used to sign the data in the first place.
(this might have been part of your original point. just trying to be
more explicit here.)

for example, if you receive a signed blob, you have to have a key to
verify the signature. common practice is to include the signing key
along with the blob in the form of an X.509 certificate. but if you
accept self signed certificates with any arbitrary subject identity, a
"bad guy" could just spin his own key, generate a self signed cert and
give it to you.

more refined PKI users know this and maintain a list of identities
they trust. so self signed certs with those identities or certs issued
under trusted roots are believed to contain public keys associated
with trusted entities.

two of the parameters in an X.509 certificate define the dates the
certificate is valid. the semantics of these fields originally bound
the issuing party to keep information about the status of the key
available during the validity period.

the problem with using signatures after a grid has long gone is that
if the certificates containing the signing keys associated with the
signatures were issued by the evaporated grid, there's no one to
maintain the status of the keys. in an X.509 PKI, relying parties
expect the key issuer to be around during the certificate's validity
period to generate CRLs or respond to OCSP queries.

the reason we have this requirement is to understand whether the
signing keys are to be trusted. when you submit a public key to a CA
for signing, buried in the CP or the CPS are policies that may require
you (the signing key holder) to agree to tell the CA if your signing
keys are compromised.

people rarely ever do this, of course, but it _is_ what we expected to
happen back when we were creating X.509.

so i guess what i'm saying is if you don't have a way of managing the
trust on signatures on individual assets, then signatures are useless
(because a bad guy could easily whip up a key pair about as easily as
it could a hash). but if you do provide a facility for trust
management using X.509 certificates on individual objects, it has the
potential to be a big mess for the end user (think about how often you
get a cert warning in your browser.)

ubiquity plus security equals a constant. so if you want to have a
virtual world where anyone can drop in and anyone can provide signed
content to the local scene graph, then it's going to be VERY hard to
insure the real or pseudonymous identity of the people who control the
keys used to sign the assets.

if you're after a more closed, less ubiquitous experience, this will
likely be less of a problem.

<plug type="shameless"> for more information about ubiquity vs.
applicability, see
http://blog.meadhbh.org/2010/08/ubiquity-vs-applicability.html </plug>

over in the VWRAP world we were tasked with synthesizing a trust model
that could work for all the group's participants. if i read david
levine's requirements correctly, he's a little more interested in this
model than linden was. i'm guessing this had to do with IBM being more
interested in things like Lotus SameTime3d and linden being more
interested (at the time) in opening the grid to a small number of
third party asset servers and simulators.

during the OGP era at linden, we were looking at ways of opening up
the grid to trusted third parties. (please don't take this to mean we
wanted to open a spigot on the side of our asset servers so any
content thief could siphon content directly out of the asset server.)
linden's business model requires the content community to have faith
in linden's ability to control illicit copying of their IP.(yes, i'm a
copyleftist and believe in fair use, but i also believe that it's the
content creator's right to select a license they find acceptable. and
linden was adamant about ensuring copy protection worked for it's
content creation community.)

so our requirements at linden were probably a little different than
enterprise & education grids or some of the more experimental OpenSim
regions out there. (though i would suspect that a number of the newer
grids aimed at content creators like InWorldz and SponOn will feel
similar pressures from their content community.)

in the linden / InWorldz / SpotOn use case, where the operator has to
make assurances to it's content creation community that content
control mechanisms work, it MAY be enough to just evaluate the
identity of a peer service. if the peer is trusted, then you simply
let them access your conmtent. the meaning of the word "trusted" in
this context is, "i trust that peer to honor the content control
meta-data of objects i give them."

it becomes a little simpler in this case, cause you don't have to
evaluate trust of each individual asset, only of the peer you may have
received the object from.

so... in conclusion...

a. signing is not a panacea.
b. it may be enough to simply trust the server that gave you an asset
c. signing individual objects is not useless, but it may have utility
limited to the "small world" use case.
d. i don't think there's a one size fits all trust model.

(wow. that was a much longer post than i thought i was going to make.
if you made it this far, i owe you a beer or a coffee or something for
sitting through my occasionally rambling verbiage. hit me up the next
time you see me...)

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * OhMeadhbh at gmail.com

On Thu, Sep 2, 2010 at 5:08 PM, Robert G. Jakabosky
<bobby at sharedrealm.com> wrote:
> Changed subject to reflect new topic, sorry for thread hijacking.  I should
> have started a new thread.
>
> On Thursday 02, Melanie wrote:
>> There is no way to prevent malicious spoofing. Leastways, no easy
>> way that doesn't involve losing data at some point or other. Even
>> keys can't be verified once the original grid has vanished.
>
> Spoofing can be prevented with signing.  People have been using public/private
> keys to digitally sign e-mail messages to authentication that the message was
> written by them and not changed/written by someone else.  If the original
> grid vanishes then all prims that where created on that grid will have the
> creator name marked with "(unverified)".  Prims only need to be verified when
> they are being imported (either from an inventory/region archive or when
> rezed from a foreign user).  If the creator's public key is still available
> and the prim's signature is invalid, then the grid can either deny the import
> or clear the creator id.
>
>> We have to accept some things can't be perfect. In the end, you have
>> a gatekeeper. Use it. Allow user only from grids you trust or have a
>> contract with.
>
> Wasn't Hypergrid trying to make it easy for users from any grid to TP to any
> other grid (as long as both are Hypergrid enabled)?
>
>> Melanie
>>
>> Robert G. Jakabosky wrote:
>> > On Monday 30, Melanie wrote:
>> >> While you have a case with using a central table, rather than
>> >> storing the URL string, and therefore the name, all over the place,
>> >> your request schema would not work.
>> >>
>> >> First off, it overcomplicates (IMO) things if you even attempt to
>> >> show the current name of an identity. My plan has been to show the
>> >> name AT CREATION TIME on a prim, e.g. the displyed creator name of a
>> >> prim will not change, even if the underlying identity changes their
>> >> name. This removes much complaxity.
>> >>
>> >> Second, your system breaks when a prim is taken to a new grid after
>> >> the grid it was created on has vanished from the internet. In that
>> >> case, even the initial lookup will fail and you have no data to display.
>> >
>> > If grids don't verify the Creator URL when receiving a prim from another
>> > grid (not the original grid where it was created), then anyone can spoof
>> > the prim's creator to be any creator from any other grid.  A spoofer
>> > would only have to create there own Hypergrid enabled region that they
>> > control and make spoofed prims (with griefer content) then hypergrid to
>> > another grid and rez a copy of the spoofed prim there.  Now they can
>> > grief people on other grids and tarnish someone else's name.
>> >
>> > hmm, there might still be a way to spoof the creator of a prim, even if
>> > the "Creator URL" is validated with the grid that creator is from.  How
>> > would Hypergrid validate the original creator for a prim that comes from
>> > some other grid?  Lets say a prim is created on grid ABC, then copied to
>> > grid XYZ, then copied to grid Acme.  How would the last grid "Acme"
>> > validate the prim's original creator?  It received the prim from a third
>> > party grid, which might be run by a spoofer.
>> >
>> > One way to stop spoofing is to add a public/private key to the creators
>> > profile (only the public key would be available to other grids) and have
>> > all exported prims be signed with the creators private key.  Then any
>> > grid receiving that prim could verify that the prim hasn't be modified
>> > using the creators public key (which would have to be requested from the
>> > "Creator URL").
>> >
>> >> Therefore, I'd prefer to go with my initial recommendation and
>> >> indeed store the URL, including the name, "all over the place". The
>> >> client view can always decide to ignore that part and to a table
>> >> lookup, or even contact the grid of origin.
>> >>
>> >> It seems that a lot of people here are all for omitting information
>> >> that would be helpful for the 90% case in order to make their
>> >> particular corner case the norm. 90% of avatars never change names.
>> >
>> > You can still get most of the speed-up you are looking for with a table
>> > that caches the URL -> display name.  I am not trying to argue against
>> > putting the display name in the URL, just against using it without
>> > verifying it.
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
> --
> Robert G. Jakabosky
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>