# Device and artifact security

**URL:** <https://hub.mender.io/t/device-and-artifact-security/1534>\
**Category:** General Discussions\
**Created:** [February 12, 2020, 11:36am UTC](https://hub.mender.io/t/device-and-artifact-security/1534 "2020-02-12T11:36:50Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![mvargasevans](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mvargasevans/32/402_2.png) [@mvargasevans](https://hub.mender.io/u/mvargasevans)\
**Post date:** [February 12, 2020, 11:36am UTC](https://hub.mender.io/t/device-and-artifact-security/1534/1 "2020-02-12T11:36:50Z")

</div>

Hi Community,

I have seen a number of posts addressing security, but it is not conclusive to me that the following two issues are addressed. Could people share or discuss what they think about it?

- Mender artifacts are signed, but not encrypted: This means that any attacker that manages to get hold of an artifact, maybe to perform usb update in emergency case, can open up the payload and take the content.

- Encrypted partitions could work (if you have the key or a method), but has this been tested with mender? The most relevant reference I found was this [https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508).

Opinions are greatly appreciated!

---

<div class="post-metadata">

**Author:** ![mvargasevans](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mvargasevans/32/402_2.png) [@mvargasevans](https://hub.mender.io/u/mvargasevans)\
**Post date:** [February 12, 2020, 12:07pm UTC](https://hub.mender.io/t/device-and-artifact-security/1534/2 "2020-02-12T12:07:14Z")

</div>

To answer my own question:  
For the artifact, you could always compressed it and encrypt that.

---

<div class="post-metadata">

**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\
**Post date:** [February 12, 2020, 12:07pm UTC](https://hub.mender.io/t/device-and-artifact-security/1534/3 "2020-02-12T12:07:27Z")

</div>

do you have sensitive data in you payload that cannot be installed via the factory image?

---

<div class="post-metadata">

**Author:** ![mvargasevans](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mvargasevans/32/402_2.png) [@mvargasevans](https://hub.mender.io/u/mvargasevans)\
**Post date:** [February 12, 2020, 12:10pm UTC](https://hub.mender.io/t/device-and-artifact-security/1534/4 "2020-02-12T12:10:22Z")

</div>

Well, thinking ahead:  
In the case of a full rootfs update, there might be some keys involved although that should be minimized anyway.

For specific file updates, that might be not a problem, but of course it would be great to ensure data integrity. For that reason, I figured that if you pack the artifact into an encrypted file, that already helps.

---

<div class="post-metadata">

**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\
**Post date:** [February 13, 2020, 8:04am UTC](https://hub.mender.io/t/device-and-artifact-security/1534/5 "2020-02-13T08:04:15Z")

</div>

Encryption would be great. Although it might take some time to work out the process and get any changes upstream. So depending on your product timeline you may need to not include keys/sensitive data in the payload for now.

---

<div class="post-metadata">

**Author:** ![SuicidalLabRat](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/suicidallabrat/32/311_2.png) [@SuicidalLabRat](https://hub.mender.io/u/SuicidalLabRat)\
**Post date:** [February 13, 2020, 10:25pm UTC](https://hub.mender.io/t/device-and-artifact-security/1534/6 "2020-02-13T22:25:00Z")

</div>

Ultimately, secrets like keys should not be stored on the file system, for a myriad of reasons, not the least of which you have cited here. However, even given an encrypted artifact, a process like this presumes the secrets are the same for all nodes the artifact is being deployed to; which, second only to no security, is the bane of IoT’s future.  
I would much rather see effort in the road map targeting PKCS#11/HSM support - but then Im biased, as all our devices include security chips that we are not yet able to utilize with Mender.

> [@PKCS11/HSM Support for authentication/authorization and signature verification](https://hub.mender.io/t/pkcs11-hsm-support-for-authentication-authorization-and-signature-verification/886):
>
> We have put significant resource into narrowing the attack surface of our device fleets, including the implementation of HSM type security/crypto modules to manage device secrets and PKI duties. The mender client is the sole component of our stack unable to leverage these security resources, where, as the highest risk vector for attacking our fleet, the OTA updating service should actually provide features supporting the highest level risk mitigation. Is there any intention to include HSM supp…

SLR-
