secure file deletion/SECRM support for JFFS2 and UBIFS

secure file deletion/SECRM support for JFFS2 and UBIFS

[Chris Packham]

Hi,

We have a customer request for "secure file deletion" for our embedded 
devices (kernel version 4.4.6). The first device is running JFFS2 on 
parallel NOR flash but we expect to see the same requirement pop up on 
our newer devices running UBIFS on top of NAND.

I found a couple of old threads related to UBIFS but they all appear to 
have fallen silent. Nothing really for JFFS2.

For our application we're not really concerned about defeating 
determined attackers who have access to the device and hardware that can 
do detailed analysis on the transistors that make up the chip. But we 
are trying to protect against casual attackers (or recipients of 
re-furbished hardware) who can run 'dd'.

So I think for us it'd be enough to implement chattr +s and have the 
file's data over written with a fixed value (e.g 0 for NOR flash) when 
it's blocks are added to the garbage collection list.

Is that something people on this list would be interested in? I realize 
JFFS2 is kind of in a twilight phase but we're really not able to 
migrate some customers away from it.

Thanks,
Chris

Re: secure file deletion/SECRM support for JFFS2 and UBIFS

[Richard Weinberger]

Chris,

On Wed, Apr 27, 2016 at 7:07 AM, Chris Packham
<Chris.Packham@alliedtelesis.co.nz> wrote:
> Hi,
>
> We have a customer request for "secure file deletion" for our embedded
> devices (kernel version 4.4.6). The first device is running JFFS2 on
> parallel NOR flash but we expect to see the same requirement pop up on
> our newer devices running UBIFS on top of NAND.
>
> I found a couple of old threads related to UBIFS but they all appear to
> have fallen silent. Nothing really for JFFS2.
>
> For our application we're not really concerned about defeating
> determined attackers who have access to the device and hardware that can
> do detailed analysis on the transistors that make up the chip. But we
> are trying to protect against casual attackers (or recipients of
> re-furbished hardware) who can run 'dd'.
>
> So I think for us it'd be enough to implement chattr +s and have the
> file's data over written with a fixed value (e.g 0 for NOR flash) when
> it's blocks are added to the garbage collection list.
>
> Is that something people on this list would be interested in? I realize
> JFFS2 is kind of in a twilight phase but we're really not able to
> migrate some customers away from it.

This is definitely a nice feature.
But please keep in mind that you can overwrite data on flash. :-)

-- 
Thanks,
//richard

Re: secure file deletion/SECRM support for JFFS2 and UBIFS

[Richard Weinberger]

On Wed, Apr 27, 2016 at 9:05 AM, Richard Weinberger
<richard.weinberger@gmail.com> wrote:
>> Is that something people on this list would be interested in? I realize
>> JFFS2 is kind of in a twilight phase but we're really not able to
>> migrate some customers away from it.
>
> This is definitely a nice feature.
> But please keep in mind that you can overwrite data on flash. :-)

Should be read "can't", of course...

-- 
Thanks,
//richard

Re: secure file deletion/SECRM support for JFFS2 and UBIFS

[Chris Packham]

On 04/27/2016 07:06 PM, Richard Weinberger wrote:
> On Wed, Apr 27, 2016 at 9:05 AM, Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
>>> Is that something people on this list would be interested in? I realize
>>> JFFS2 is kind of in a twilight phase but we're really not able to
>>> migrate some customers away from it.
>>
>> This is definitely a nice feature.
>> But please keep in mind that you can overwrite data on flash. :-)
>
> Should be read "can't", of course...
>

You can't overwrite with arbitrary data. But for NOR flash at least you 
_can_ overwrite with 0 (at least I think you can). In other words if the 
erased state is 0xff you can write 0xaa you would not be able to write 
0x55 without erasing the block first but you would be able to write 0x00.

I was hoping to avoid having to do an immediate erase but if I'm wrong 
that's what we'd have to do.

Re: secure file deletion/SECRM support for JFFS2 and UBIFS

[Richard Weinberger]

Am 27.04.2016 um 23:49 schrieb Chris Packham:
> On 04/27/2016 07:06 PM, Richard Weinberger wrote:
>> On Wed, Apr 27, 2016 at 9:05 AM, Richard Weinberger
>> <richard.weinberger@gmail.com> wrote:
>>>> Is that something people on this list would be interested in? I realize
>>>> JFFS2 is kind of in a twilight phase but we're really not able to
>>>> migrate some customers away from it.
>>>
>>> This is definitely a nice feature.
>>> But please keep in mind that you can overwrite data on flash. :-)
>>
>> Should be read "can't", of course...
>>
> 
> You can't overwrite with arbitrary data. But for NOR flash at least you 
> _can_ overwrite with 0 (at least I think you can). In other words if the 
> erased state is 0xff you can write 0xaa you would not be able to write 
> 0x55 without erasing the block first but you would be able to write 0x00.
> 
> I was hoping to avoid having to do an immediate erase but if I'm wrong 
> that's what we'd have to do.

Well, UBIFS and JFFS2 work on generic MTD, so having a special hack for NOR
is not really what we want.

Thanks,
//richard

Re: secure file deletion/SECRM support for JFFS2 and UBIFS

[Chris Packham]

On 04/28/2016 09:55 AM, Richard Weinberger wrote:
> Am 27.04.2016 um 23:49 schrieb Chris Packham:
>> On 04/27/2016 07:06 PM, Richard Weinberger wrote:
>>> On Wed, Apr 27, 2016 at 9:05 AM, Richard Weinberger
>>> <richard.weinberger@gmail.com> wrote:
>>>>> Is that something people on this list would be interested in? I realize
>>>>> JFFS2 is kind of in a twilight phase but we're really not able to
>>>>> migrate some customers away from it.
>>>>
>>>> This is definitely a nice feature.
>>>> But please keep in mind that you can overwrite data on flash. :-)
>>>
>>> Should be read "can't", of course...
>>>
>>
>> You can't overwrite with arbitrary data. But for NOR flash at least you
>> _can_ overwrite with 0 (at least I think you can). In other words if the
>> erased state is 0xff you can write 0xaa you would not be able to write
>> 0x55 without erasing the block first but you would be able to write 0x00.
>>
>> I was hoping to avoid having to do an immediate erase but if I'm wrong
>> that's what we'd have to do.
>
> Well, UBIFS and JFFS2 work on generic MTD, so having a special hack for NOR
> is not really what we want.

Agreed. I was hoping there was a similar trick for NAND which I'm less 
familiar with. The fallback behavior of an immediate erase is still 
doable but it has more corner cases that we'd need to be weary of.

Re: secure file deletion/SECRM support for JFFS2 and UBIFS

[Richard Weinberger]

Am 28.04.2016 um 00:35 schrieb Chris Packham:
>> Well, UBIFS and JFFS2 work on generic MTD, so having a special hack for NOR
>> is not really what we want.
> 
> Agreed. I was hoping there was a similar trick for NAND which I'm less 
> familiar with. The fallback behavior of an immediate erase is still 
> doable but it has more corner cases that we'd need to be weary of.

Nope, on NAND you're forced to erase.
Also erase itself is a problem (at least on UBIFS), it does not erase blocks
synchronous and also not immediately after they are no longer needed.
So, you'd have to touch some code...
Blindly doing a synchronous erase will hurt the performance as you
block the callers.

Thanks,
//richard

Re: secure file deletion/SECRM support for JFFS2 and UBIFS

[Ricard Wanderlof]

On Thu, 28 Apr 2016, Richard Weinberger wrote:

> Am 28.04.2016 um 00:35 schrieb Chris Packham:
> >> Well, UBIFS and JFFS2 work on generic MTD, so having a special hack for NOR
> >> is not really what we want.
> > 
> > Agreed. I was hoping there was a similar trick for NAND which I'm less 
> > familiar with. The fallback behavior of an immediate erase is still 
> > doable but it has more corner cases that we'd need to be weary of.
> 
> Nope, on NAND you're forced to erase.

I know generally there is a recommendation not to overwrite bits already 
set to 0 with 0 for NAND, but I can't remember if that is related to the 
subsequent readability of surrounding data, or if may cause a future erase 
not to perform properly, or actually physically damages the bit cell (or 
there is some other reason).

If it's just related to the readability of surrounding bit cells, one 
could imaging overwriting a page with zeros since we were not going to 
read it anyway.

With MLC it's going to be a problem though due to bits being paired 
between separate pages.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: secure file deletion/SECRM support for JFFS2 and UBIFS

[Richard Weinberger]

Am 28.04.2016 um 10:40 schrieb Ricard Wanderlof:
> 
> On Thu, 28 Apr 2016, Richard Weinberger wrote:
> 
>> Am 28.04.2016 um 00:35 schrieb Chris Packham:
>>>> Well, UBIFS and JFFS2 work on generic MTD, so having a special hack for NOR
>>>> is not really what we want.
>>>
>>> Agreed. I was hoping there was a similar trick for NAND which I'm less 
>>> familiar with. The fallback behavior of an immediate erase is still 
>>> doable but it has more corner cases that we'd need to be weary of.
>>
>> Nope, on NAND you're forced to erase.
> 
> I know generally there is a recommendation not to overwrite bits already 
> set to 0 with 0 for NAND, but I can't remember if that is related to the 
> subsequent readability of surrounding data, or if may cause a future erase 
> not to perform properly, or actually physically damages the bit cell (or 
> there is some other reason).

I have been told that overwriting data on NAND can lead to physically damage,
but don't ask for a reference. ;-)
Maybe NAND fracturing folks can give more details on this topic.

Thanks,
//richard