If they do come back to the same network and you just happen to be on and looking.
From the command line.
arp -an
This will show you the IP and MAC addresses of any hosts active on the network at that time.
$arp -an
? (10.0.1.1) at e4:ce:8f:68:85:c8 on en1 ifscope [ethernet]
? (10.0.1.13) at 0:19:7e:b0:37:ff on en1 ifscope [ethernet]
? (10.0.1.20) at 64:b9:e8:2b:ab:97 on en1 ifscope [ethernet]
? (10.0.1.28) at d8:30:62:76:ab:a0 on en1 ifscope [ethernet]
? (10.0.1.255) at ff:ff:ff:ff:ff:ff on en1 ifscope [ethernet]
This will at least tell you if your computer is back on the network. I doubt they would go through the trouble of spoofing the MAC address.
Did you have Remote login turned on? If so and it shows on the network, you could login to your computer. This opens up more options.
Such as:
You could SSH into your computer.
Once in you could run something like this.
while : ; do sudo osascript -e "set Volume 10" && say here i am && sleep 30 ; done &
Adjust "here i am" to what ever you want your Mac to say at full volume. I put a sleep 30 in to keep them from just powering it off right away and give you time to find them. It would probably take them a few times to figure out that it was the Mac talking. I'd scope out the Macs in the area before running it so I'd know where to look first.
The system keychain is stored in /Library/Keychains/System.keychain and the key to unlock it is stored in /var/db/SystemKey (its default file permissions are readable by root only). The location of these files is referenced in the security-checksystem script (from the security_systemkeychain source). It is even possible to test to automatic locking/unlocking of the system keychain by using
systemkeychain -vt
The keychain security framework allows non-privileged programs to make requests for information provided they are in the ACL stored within the keychain entry. Obviously if a user has root they on a system they can directly access both the file storing the system keychain and the key to unlock it, thus they do not have make requests via the security framework and are not beholden to the ACLs stored within the keychain itself.
(I didn't actually answer the original questions so let's give this another go)
How are the keys architected such that any administrative user can unlock the System Keychain?
The libsecurity keychain framework allows regular processes to interact with the system keychain in an authenticated manner using Apple's XPC interprocess communication framework (IPC).
Program A sends a request to access the system keychain information using IPC. A check is made that the requesting user is already in the wheel group and also knows the password of a user in the wheel group. Once authorization is confirmed, the privileged kcproxy daemon can be used to access material in /var/db/SystemKey, unlock the system keychain and return the requested information.
Are there cryptographic restrictions that limit what an administrative user can do with information in the System Keychain in any way?
No - an administrative user is allowed to access/change anything in the system keychain. Even if they couldn't, they could copy the underlying files to another machine on which they have complete control and just unlock/access it there.
Given an unencrypted system backup without /Users, how would you gain access to the keys in the System Keychain?
If the backup contained copies of /Library/Keychains/System.keychain and /var/db/SystemKey then I would copy them to their respective locations on a new OS X system and use systemkeychain to make the later unlock the former and dump the keychain database using security dump-keychain.
Best Answer
Yes, its secure.
Note: The following is way more info then anyone needs but I thought why not.
A while back, around when the internet was created, HTTP, or the Hypertext Transfer Protocol, was created to transfer website data. -- Wait I've seen that before -- Yes you have. In a URL the first section specifies the protocol so when connecting to http://example.com you are using the HTTP protocol. When connecting to ftp://example.com you are using, yes you guessed it, the FTP protocol, or File Transfer Protocol. HTTP is an insecure protocol that send data over plain text. Meaning anyone connected to (or not connected to) the WiFi network can snoop on all passwords, credit cards, addresses, etc. sent over the internet.
More Info: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
iCloud, Google, StackExchange, Yahoo, Chase Bank, Twitter, Spotify, and basically every website (hopefully) that requires you to login or submit information uses an addition to the HTTP protocol called HTTPS, or HTTP + SSL, or secure sockets layer (Yes, us computer people like to shorten things). (In fact, you're using it right now. Look at the URL in on your browser. See the HTTPS?) SSL Encryption is EXTREMELY secure (How Secure?, you ask). This prevents any data from being snooped on by other people. It encrypts all data sent between the client (you) and the server (the server the website is hosted on).
So, since iCloud uses HTTPS all the information is secure even if you are on an insecure network.