Elipsa 2E Encrypting Kobo device?

[HarryEngineer]

Has anybody successfully encrypted their Elipsa 2E? Or any kobo device for that matter?

[JSWolf]

Originally Posted by HarryEngineer

Has anybody successfully encrypted their Elipsa 2E? Or any kobo device for that matter?

Why? Why?

[HarryEngineer]

Originally Posted by JSWolf

Why? Why?

If lost, or intentionally stolen, the new user would have to know the password to access any content.

Without encryption, anybody can access all your notes, content, highlights, etc.

in addition to lost/stolen, somebody with temporary access to your kobo could also plug it into their pc and copy all contents. Entire device encryption would prevent them from making use of anything without the password.

[HarryEngineer]

Originally Posted by JSWolf

Why? Why?

If you lost, or had your kobo stolen, somebody could see/save all your content, notes, highlights, etc.

Also, somebody with temporary access to your device(whilst your at work, not at home, etc) would be able to connect via USB and copy/paste your data.

With full device encryption, a password has to be entered to access, even copy/paste via usb would be useless without password.

[JSWolf]

I;ve never read of any Reader being encrypted.

[DNSB]

The Sony DPT for one had encryption. The corporate ecosystem demanded that.

Kobo's PIN access does some of what the OP wants for access control but there is no encryption of content done. The Sage and Elipsa are about the only Kobo devices that have enough CPU power to make encryption doable.

[Aleron Ives]

Kobo devices use a stripped-down version of Linux. You can't encrypt anything.

[DNSB]

Originally Posted by Aleron Ives

Kobo devices use a stripped-down version of Linux. You can't encrypt anything.

For what it may be worth, you could, in theory, use ext4 FBE or LUKS on a Kobo ereader. As to whether it would be worthwhile considering the extra CPU load is up to the user (performance hit is >50%).

[Aleron Ives]

Wouldn't that require reformatting the user partition from FAT32? Is that allowed?

[HarryEngineer]

Originally Posted by DNSB

The Sony DPT for one had encryption. The corporate ecosystem demanded that.

Kobo's PIN access does some of what the OP wants for access control but there is no encryption of content done. The Sage and Elipsa are about the only Kobo devices that have enough CPU power to make encryption doable.

Do you recall which DPT? The older or newer?

Originally Posted by Aleron Ives

Kobo devices use a stripped-down version of Linux. You can't encrypt anything.

as its linux based it should be possible.

Originally Posted by DNSB

For what it may be worth, you could, in theory, use ext4 FBE or LUKS on a Kobo ereader. As to whether it would be worthwhile considering the extra CPU load is up to the user (performance hit is >50%).

I was thinking LUKS, apparently some attack vectors are possible in ext4 FBE via access to parts of the unencrypted config/operating system/files, etc

If you say it should be do-able on an elipsa, then the 2E should be even moreso?


Taken from the LUKS wikipedia https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup

On mobile Linux systems, postmarketOS has developed osk-sdl to allow a full disk encrypted system to be unlocked using a touch screen.
https://wiki.postmarketos.org/wiki/Osk-sdl

May offer another avenue

[HarryEngineer]

Originally Posted by Aleron Ives

Wouldn't that require reformatting the user partition from FAT32? Is that allowed?

The wiki page on LUKS states

LUKS is used to encrypt a block device. The contents of the encrypted device are arbitrary, and therefore any filesystem can be encrypted, including swap partitions.

...

A common usage of LUKS is to provide full disk encryption, which involves encrypting the root partition of an operating system installation, which protects the operating system files from being tampered with or read by unauthorized parties.

On a Linux system, the boot partition (/boot) may be encrypted if the bootloader itself supports LUKS (e.g. GRUB). This is undertaken to prevent tampering of the Linux kernel. However, the first stage bootloader or an EFI system partition cannot be encrypted (see Full disk encryption#The boot key problem).


https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup

[DNSB]

Originally Posted by HarryEngineer

Do you recall which DPT? The older or newer?

As far as I am aware, both versions. It was something the law firm I did some work for that owned several of them considered a necessity and had issues with trying to find when they were looking for replacements.

Originally Posted by HarryEngineer

I was thinking LUKS, apparently some attack vectors are possible in ext4 FBE via access to parts of the unencrypted config/operating system/files, etc

If you say it should be do-able on an elipsa, then the 2E should be even moreso?

The original Elipsa had the same quad core processor as the Sage. The 2E has a dual core processor which reduced the power draw. I suspect that may affect it's performance with encryption.

[elinkser]

I checked and InkBox is indeed using filesystem encryption, as well as other measures that make it far more secure than the stock Kobo system.
https://inkbox.ddns.net/wiki/index.php?title=Main_Page

- Increases storage security by adding two-factor authentication (2FA). When the EncFS volume key is stored outside the encrypted source directory and into a physically separated location from the actual encrypted data, it significantly increases security by adding a two-factor authentication (2FA). For example, EncFS is able to store each unique volume key anywhere else than the actual encrypted data, such as on a USB flash drive, network mount, optical disc or cloud.[6] In addition to that a password could be required to decrypt this volume key.

Advantages
- EncFS offers several advantages over other disk encryption software simply because each file is stored individually as an encrypted file elsewhere in the host's directory tree.

https://en.m.wikipedia.org/wiki/EncFS



So that would appear to address two issues:
1. Your Ellipsa 2e is not supported by InkBox yet.
2. If you got it supported, you would still be missing the proprietary gesture recognition software. According to Quoth and others, this functionality is not as advanced in FOSS.
So you are relegated to keyboard input, or uneditable images of text, or maybe immature gesture recognition software.


Maybe you could encrypt directoryies instead of a filesystem, and only temporarily unencrypt the part that needs access or syncing? Not sure if it is feasible...

* Not implying this is a "secure" practice, as you are still open to corruption of the system, including by network attacks. Inkbox takes a total system approach which is more effective,

[lumping-sugar66]

You could implement a lock/unlock mechanism with either symmetric or asymmetric key cryptography methods. It’s one step away from designing a ransomware app but the point stands, go though each file under /mnt/onboard and encrypt them to decrypt later.

[HarryEngineer]

Thanks elinkser & lumping-sugar66

I will be looking more into your suggestions tonight!