[Honor 8 Questions & Answers] schlimmchen:
This is my conclusion as well (recovered to EMUI4.1 via stock eRecovery and upgraded to EMUI5 immediately).

HWFRD:/ $ getprop | grep crypt
[ro.crypto.fs_crypto_blkdev]: [/dev/block/dm-5]
[ro.crypto.fuse_sdcard]: [true]
[ro.crypto.state]: [encrypted]
[ro.crypto.type]: [block]
[vold.crypto_unencrypt_updatedir]: [/data/update]
[vold.decrypt]: [trigger_restart_framework]

This seems promising, but in reality the "default_password" must be protecting the storage. OpenKirin's TWRP mounts the data without the need for a pin/password/pattern and android starts without one, too. I did not check whether the /data partition is encrypted at all or if the props are elaborately faked, but the /data partition is definitely not protected.

I tried to make Android file based encryption (FBE) using ext4 happen for the FRD, using OpenKirins (github.com/OpenKirin) kernel (android_kernel_huawei_hi3650), device (android_device_honor_frd) and vendor (android_vendor_honor_frd) repos combined with LineageOS 14.1.

After

enabling EXT4_CRYPT in the kernel, which seemed to work just fine

adjusting the fstab to fileencryption=ice/software

preventing the phone from rebooting immediately and wiping /data due an error

starting adb early with ro.adb.secure = 0 to grab logs

fiddling with the proprietary blobs

the "HisiKeyMaster" showed up in the logcat, which was promising, because it was invoked by vold to init FBE. However, it according to the logs the keymanager fails immediately (even with keystore and gatekeeperd started in early-init) and I am out of ideas, especially because the error touches proprietary blobs and the only option from my point of view is to fiddle some more with including blobs from /vendor to make the thing work, which did not help.

Maybe the initialization in init must be changed so that the keymaster can init prior to android trying to use it.

There were configurations where the HisiKeyManager seemed to have initialized correctly

75:08-12 11:35:21.577 373 373 I HisiKeyMaster: hisi_km_open start
129:08-12 11:35:21.643 373 373 I HisiKeyMaster: hisi_km_open success
132:08-12 11:35:21.644 373 373 I HisiKeyMaster: hisi_km_configure start
133:08-12 11:35:21.653 373 373 I HisiKeyMaster: open first km session
134:08-12 11:35:21.656 373 373 I HisiKeyMaster: hisi_km_configure success

but in the same session vold failed to create a new FBE key using the keymanager HAL:

08-12 15:45:00.492 311 321 E vold : keymaster2_open returned -16

Or initializing the keymanager would fail by itself (with a different mix of blobs in /system):

08-12 14:59:04.752 382 382 E HisiKeyMaster: open km session failed, ret=0xffffcfe5, origin=3
08-12 14:59:04.752 382 382 E HisiKeyMaster: TEE_KmConfigure failed, ret=0xffffcfe5

So from my point of view it's not gonna happen that the honor 8 is properly encrypted. Not without implementing a gatekeeperd that uses some hidden file on /data to manage the keys (like LUKS does).

I was going to restore EMUI 5 from a TWRP backup to check the logs whether the HisiKeyMaster shows up working in there at least, but the backup is not booting, so I finally cancel this mission.

BTW: Looking at this utterly failed so called "encryption" in EMUI and the failing HisiKeyMaster, I get this gut-feeling that it is not by choice that Huawei did not introduce FBE for the EMUI5 (which should be the case, IMHO). Maybe their implementation is flawed, maybe even the hardware is, and they recognized this too late. It's a bold idea, but it could be. Not just to cover up my failure to make FBE happen, but also to explain that they did not implement proper FBE at all in EMUI5, which *is* based on Android 7 afterall.