I did a training for a contractor for the USA Dept of Energy this week and these detailed questions came up that I couldn't quite answer on the spot. I opened ticket # 775555 that is summarized below and may be helpful to you as well. Enjoy if so.
Do we have any documentation around the process flow for how .awsec files are
created by the SEG? Further, where any related encryption key is generated,
stored and passed on to the device?
Then any guidance/details around how this could be compromised and any safeguards around how any cert could be used maliciously to open an .awsec file outside of normal use cases.
The process flow is described below:
Device enrolls with AirWatch
Create an encryption key unique to user/device combination
Encryption key is stored in the cache of the SEG
Device syncs for email or downloads attachments
SEG proxies request through to EAS server if request is allowed
EAS server responds with content
SEG encrypts attachment, applies new file header and appends new .awsec file type
AWSEC file type unique to SCL and can only be read by SCL
Header is uniquely generated for each attachment, so each attachment is encrypted uniquely
Encrypted attachment is received by the device and SCL checks its keystore for an encryption key whose hash matches the hash in the file header
If verification passes, the file is decrypted and can be viewed in the SCL
If verification fails, the SCL calls an endpoint to retrieve the encryption key and once SCL receives it, SCL decrypts the file
The device creates an encryption key when it’s enrolled.
The Encryption key is stored in the SEG cache.
The attachments sent to the SEG have the mime type changed to awsec along with the file name appending the .awsec.
When you say the header is uniquely generated, is this the mime type?
How does the AWDS send files to the devices? Are these sent encrypted at the transport layer and not at the file layer?
Yes and yes. The header has the mime type in it and the files are sent at the transport layer.
