lkml.org 
[lkml]   [2015]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] modsign: use shred to overwrite the private key before deleting it
Am 25.01.2015 um 11:32 schrieb Alexander Holler:
> Am 25.01.2015 um 03:43 schrieb Alexander Holler:
>> Am 25.01.2015 um 03:13 schrieb Pádraig Brady:
>>> On 24/01/15 12:29, Alexander Holler wrote:
>>>> Am 24.01.2015 um 13:09 schrieb Alexander Holler:
>>>>> Am 24.01.2015 um 12:37 schrieb Alexander Holler:
>>>>>> Am 24.01.2015 um 11:45 schrieb Alexander Holler:
>>>>>>
>>>>>>> It uses shred, in the hope it will somedays learn how to shred
>>>>>>> stuff on
>>>>>>> FLASH based devices securely too, once that has become possible.
>>>>>>
>>>>>> BTW: This is a good example where technology failed to keep the
>>>>>> needs of
>>>>>> users in mind.
>>>>>
>>>>> Failed completely.
>>>>>
>>>>> Since ever it's a problem for people to securely delete files on
>>>>> storage.
>>>>>
>>>>> Also it should be very simple to securely erase files on block based
>>>>> devices, people have to try cruel ways in the hope to get securely rid
>>>>> of files nobody else should be able to see ever again.
>>>>>
>>>>> It's almost unbelievable how completely the IT industry (including the
>>>>> field I'm working myself: SW) failed in regard to that since 30
>>>>> years or
>>>>> even more.
>>>>
>>>> And it isn't such that this is a new requirement. Humans are doing such
>>>> since thousands of years. They use fire to get rid of paper documents
>>>> and even the old egypts were able to destroyed stuff on stones by using
>>>> simple steps. Just the IT failed completely.
>>>>
>>>> Really unbelievable.
>>>>
>>>> So, sorry if anyone got bored by this mail, but I think that really has
>>>> to be said and repeated.
>>>
>>> Well not failed completely, just used a different method (encryption).
>>>
>>> As for "shredding", that improves in effectiveness the lower you go.
>>> I.E. it's effective for the whole file system (SSD range), or whole
>>> device.
>>
>> That's the usual broken way to go by adding another layer. And if you
>> encrypt your whole device, it won't help if you want to delete one file.
>> As long as the encrypted device is mounted and the blocks aren't
>> overwritten, the stuff is still there. So your solution would end up
>> with:
>>
>> - mount encrypted device
>> - build kernel and secret key
>> - install kernel and secret key
>
> That's wrong, of course it should read "and signed modules".
>
>> - unmount encrypted device
>>
>> That's almost the same as shredding a whole device just to securely
>> delete one file, with the added complication that the encryption
>> requires an authentication, which usually is very uncomfortable to do,
>> at least if the authentication is somewhat secure.
>>
>> Or what do you have in mind?
>>
>> Sorry, but deleting a file such that it isn't readable anymore by anyone
>> shouldn't be a complicated sequence of geek-stuff and all filesystem and
>> storage designers should be ashamed that they haven't managed it in
>> around 30 years to accomplish that simple goal. (imho) ;)
>
> By the way, I still remember the time when people learned that if they
> delete a file on a FAT file system, it isn't really gone. Afterwards all
> kinds of device-shredding software and hardware appeared.
>
> But instead of fixing that broken design, now, around 30 years later,
> this stupid and broken design is almost part of any storage and filesystem.
>
> And even worse, because storage is nowadays often fixed to device (no
> floppy anymore you can easily destroy), it often has become almost
> impossible to really delete stuff on devices.
> E.g. how do you overwrite an eMMC which is soldered, without the
> possibility to boot from something else in order to launch the shredding
> software?
>
> So we are now at the point that the only way to keep some information
> private (forever) is to not store it on any computer.
>
> How crazy or userfriendly is that?

I've filed bugs #92271 (ext4) and #92261 (btrfs) in the kernels
bugzilla. That might be a more appropriate place for discussion. Here
are the links:

https://bugzilla.kernel.org/show_bug.cgi?id=92271

https://bugzilla.kernel.org/show_bug.cgi?id=92261

Regards,

Alexander Holler



\
 
 \ /
  Last update: 2015-01-30 00:01    [W:0.070 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site