How do I secure my listen() during detach?

[smoothazndude]

I am working on a listener that I wear which uses the listen() event to perform an action when receiving a message from another item that I am also wearing.  I want a piece of clothing to send a notification to the listener upon attach and detach.

When I wear/attach an item, that piece of clothing successfully sends the message to my listener through a common channel that both listener and sender know.

The listener then makes sure to only listen to messages that originate from my avatar via:
 

if (llGetOwnerKey(id)==llGetOwner()){

// this message came from myself, so do the work

}

The trouble arises when the piece of clothing that is getting detached sends a message to the listener.  The check for llGetOwnerKey(id) does appear to work since the id is of a piece of clothing that has been detached and is gone.

Has anyone solved this issue with securely processing in a listener of messages from objects that have been detached?

[Fenix Eldritch]

As you've already seen, attempting to use llgetOwnerKey on an incoming message from an object that just detached will not work, because the owner info is already lost. The function will just return the same key that was fed to it.

From the caveats of llGetOwnrKey:

Quote

• Returns id if id is not found in the region or is not a prim.
  • Owner information becomes unavailable immediately on derez or detach. For example, if a prim chats at derez or detach time, id can be returned even inside listen events of nearby objects.

 

So to add an extra layer of security to your message processing, you'll have to get creative with existing listen filters. A shared secret channel both objects know about is an obvious start. There are methods for generating a number based off of a supplied key, so your clothing and listener could use that formula and supply the same key (you, the owner). After that, you could try giving your objects a common naming convention and then have your listener inspect the incoming message's speaker's name to see if it fits your template. Similarly, you could do the same for the actual message itself. Depending on how your system works, you could have a separate listener just for the detaches, where your clothing objects broadcast the same detach message that the listener is explicitly listening for (meaning it would reject all other messages that aren't an exact match to what it expects.

Also, it may be prudent to have your clothing attachments communicate their detach messages via llRegionSayTo, targeting their owner (i.e. you). Messages sent to avatars on non-public channels aren't seen by the viewer, but all worn scripted attachments listening on that channel can hear it. This would be a good way to ensure your clothing items are only talking to you (or your listener) and not sending their messages out for anyone who happens to be listening on the same channel to hear and potentially try to spoof.

Edited September 11, 2023 by Fenix Eldritch

[smoothazndude]

Thanks for the suggestions.  I thought there would be something easier.  But I have implemented a quick shared secret solution that has the sender llRegionSayTo() (vs what I was using before with just llSay()).  That option sounds a lot more secure.  I have the listener check and match the shared secret embedded in the message sent by the sender.

I did a little research and thought about having the sender use llSignRSA() using a private key to produce a signature that can get sent along with the message and the listener can use the public key to perform llVerifyRSA() on the message's signature to verify the authenticity of the sender.   That seems a little bit of an overkill though would be more secure than a simple shared secret.

Overall, much obliged by your response and suggestion.  I got my little sender and listener working with a simple shared secret and the llRegionSayTo().  Perfect for the little project I am working on. Cheers!

[Quistess Alpha]

2 hours ago, smoothazndude said:

llSignRSA() using a private key to produce a signature

I agree that's overkill, just the length of the key would make me a bit wary of using it for script communication given the 1024 byte message limit. XTEA could be more suitable, but IMO it's still overkill for most use-cases.

[Bleuhazenfurfle]

Are you sure it's actually necessary?  Usually if you care about detatch, it's because you've been interacting with the object and have already authenticated it in some way — and are probably checking on it every now and again in case they skip the sim before detaching it.  That usually implies you already know it's key, and a simple check of the UUID will do.  Maybe not in this case, just thought it was worth mentioning in case you're over-thinking it all.

[primerib1]

Yeah I would recommend to simply use a kind of session ID / session token. With a sufficiently hard-to-guess secret channel, and directed messaging using llRegionSayTo(), a randomly-generated session token is more than enough to prevent confusion.