Als je software encryptie toepast (een driver in je besturingssysteem) dan is de data die op je SATA bus gaat al versleuteld en zal alle data op je SSHD dus versleuteld zijn. (Aangenomen dat er geen onversleutelde partities op je "schijf" staan.)

http://www.pcworld.com/article/254509/free_tools_to_wipe_your_drives_securely.html

SSD's kun je niet wipen door te overschrijven (reservecellen worden niet overschreven), secure erase wordt lang niet altijd ondersteund.

En als het wel wordt ondersteund niet altijd correct (of zelfs helemaal niet) uitgevoerd.
zie: https://www.usenix.org/legacy/event/fast11/tech/full_papers/Wei.pdf

T.s. hier


Als ik een secure partitie heb en aan het werk ben met die partitie omdat o.a. mijn OS daarop staat dan lijkt mij dat de partitie op dat actieve moment ontsleuteld is.

Naar wat ik begrijp is dat een SSHDisk een traditioneel deel heeft, de gewone HD (harddisk) in combinatie met een kleine SSD (Flash?) disk.
Op die SSD achtige disk worden de meest gebruikte bestanden opgeslagen zodat die sneller kunnen worden aangeroepen.
Die bestanden worden daar los van het tussentijds steeds apart booten van de pc opgeslagen om het werken sneller te maken.
Immers, data ophalen vanaf dat SSD deel gaat sneller dan van het traditionele deel.

De data op het traditionele deel is encrypted in haar geheel als disk.
Wat ik mij dus afvraag is hoe dat zit met de meest aangeroepen data op de SSD disk.
Met andere woorden, mijn indruk is dat daar bestanden op staan die op het moment dat de andere disk in bedrijf was en dus unencrypted was eraf zijn geplukt om ze op de SSD als kopie te bewaren zodat ze sneller aanroepbaar zijn.

Volgens die logica zou het erop lijken dat die data dan soort van permanent als kopie unencrypted en wel op de SSD disk staan, dus los van het rebootproces en het versleutelen en ontsleutelen van de traditionele en encrypted disk in die SSHDisk.

Heb ik het zo beter uitgelegd?
Hopelijk.
Blijft het antwoord hetzelfde?
Licht dat svp dan eens nader toe zodat het begrijpelijk wordt voor 'dummies'. ;)

Wat de overige bijdragen betreft, dat slaat meer op één van de twee situaties, een SSD of een traditionele HD, maar het gaat me nou juist om die combidisk : SSHD !

In de hoop dat er nog iemand inspringt of het antwoord weet want encryptie op zich is hier een veelbesproken (hot) item.
Dank alvast.

Nee, zo werkt het niet. Schijven werken met blokken van vaste grootte (sectors of sectoren genoemd), bijv. 512 of 4092 bytes; de controller in een schijf heeft geen flauw benul van "bestanden" (maar ook niet van partities en mappen/directories). Elk blok heeft een nummer (dat zou je ook een adres kunnen noemen).

Het besturingssysteem op jouw PC (om precies te zijn: de file system driver) houdt, per bestand, bij welke blokken (bloknummers) op de schijf dat bestand vormen.

Elke harde schijf heeft geheugen (RAM = Random Access Memory) aan boord dat dient als buffer tussen de draaiende schijf en de kabel naar het moederbord van de PC. Als een blok van de draaiende schijf gelezen wordt, komt dat eerst in dat geheugen te staan. Zodra het hele blok in de buffer staat, wordt het (veel sneller dan het lezen ging) naar het geheugen van jouw PC getransporteerd.

Bij elke harde schijf die ik ken is dat geheugen veel groter dan 1 blok, en houdt de schijf bij welke blokken relatief vaak worden gelezen; die probeert de controller van de schijf dan in RAM te houden, zodat ze veel sneller geleverd worden als de PC erom vraagt. Veel zin heeft dit tegenwoordig niet meer, want besturingssystemen reserveren (mits je voldoende geheugen in je PC hebt) aanzienlijk meer geheugen (op je moederbord) voor ditzelfde doel.

Een probleem met RAM is dat het alle informatie vergeet als je de voedingsspanning eraf haalt. Dat geldt niet voor flashgeheugen. Dan nu de truc: als de controller in de schijf de blokken, die altijd tijdens booten worden gelezen, in flashgeheugen houdt, start de PC sneller op!

Echter, welke informatie er precies in dat flashgeheugen staat, weet je niet zeker. Het kan ook zijn dat de controller als strategie heeft om de vaakst gelezen blokken in flashgeheugen te houden (in plaats van direct na opstarten gelezen blokken).

Dus, als jij heel vaak een tekstbestandje met al jouw wachtwoorden + URL's opent, kun je niet uitsluiten dat net die informatie in flash blijft zitten.

Als je die schijf verkoopt, nadat je deze met nullen hebt overschreven (1x overschrijven is zat), of weggooit omdat hij kapot is, bestaat de kans dat jouw wachtwoorden nog in het flashgeheugen staan. Gelukkig kan iemand die de schijf gewoon op een PC aansluit, daar -normaal gesproken- niet bij.

Helaas kan dat mogelijk wel op de volgende manieren (en wellicht nog andere):
1) Als de fabrikant de controller (firmware) zo heeft gemaakt dat met software op de PC het flashgeheugen direct kan worden uitgelezen, en de aanvaller over zulke software beschikt;
2) Als het de aanvaller lukt om de firmware zo te wijzigen dan 1 mogelijk is (voorwaarde is wel dat de hardware = chips in de schijf dit ondersteunen, maar vanwege debug- en testmogelijkheden is dit vast het geval);
3) Als de aanvaller de flashchips lossoldeert en zelf uitleest.

De vraag is natuurlijk of iemand zoveel moeite overheeft voor wat data van jouw schijf. Verder zie deze discussie: https://www.security.nl/posting/456536/Vernietigen+van+Flash+memory+devices.

Het uitleggen van deze materie, is nogal lastig als je geen kaas gegeten hebt van de -hardwarematige- werking van een systeem.

Ik spring wel in dan, en begin met een zo kort mogelijke uitleg, om vervolgens, op chronologische volgorde, verder in te gaan op je reactie.

Start hier: (plaatje) https://upload.wikimedia.org/wikipedia/commons/b/bd/Motherboard_diagram.svg
En hou dat plaatje bij nog even bij de hand.
Het lijkt allemaal verdacht veel op de (elektrische) signaalverwerking van het menselijk lichaam / het systeem achter de postbezorging, misschien dat dat het wat makkelijker maakt:

Stap 1 - Data staat op datadrager.
USB stick, DVD, SSHD, netwerk, maakt niet uit waar.
- In dit voorbeeld is de (ruwe) data natuurlijk versleuteld.

Stap 2 - Data wordt aangeroepen.
De (ruwe, versleutelde) data gaat (via een bus) naar de Southbridge (zie plaatje!), waar bepaald wordt wat er gebeuren moet.
- Als je de data alleen wilt kopiëren van SSHD naar een USB stick, gaat de data vanaf de opslaglocatie op schijf, via de SSHD-controller, over de SATA-bus (= aansluiting SSHD), naar de Southbridge (postsorteercentrum), om vanuit daar, via de USB-bus, langs de USB-controller in de stick, naar de beoogde opslag-locatie (einddoel) te gaan.
- Encryptie doet, tot zover, helemaal niet ter zake.

Stap 3 - Data moet verwerkt worden.
Als de data nodig is voor de werking van het systeem, gaat deze (nog steeds ruwe, versleutelde) data naar de Northbridge.
- Nu wordt het ingewikkeld, dus om het héél simpel te houden, wordt de data pas ontsleuteld zodra het de Northbridge bereikt.
- De Northbridge is het echte 'brein' van een systeem, hier zijn de klok, CPU, GPU, en het RAM met elkaar verbonden. Pas hier worden daadwerkelijk gegevens verwerkt, al het andere is in feite data-logistiek (transport & opslag).

Stap 4 - De data moet, na verwerking, terug op de datadrager worden geplaatst.
Als er data terug moet naar het lange termijn geheugen (SSHD, USB, DVD = alle datadragers), wordt de data, indien nodig, éérst versleuteld.
- Daarna wordt de (nu weer ruwe, versleutelde) data naar de Southbridge gestuurd, vanuit waar het weer, via de juiste bus, naar het einddoel (netwerk, schijf, USB, wat dan ook) gaat.

Kun je het nog volgen? Best een mooi systeem, toch?


Inhoudelijk op je laatste reactie:
A] De data is wel ontsleuteld in het werkgeheugen (RAM) opgeslagen, maar niet op de datadrager, ongeacht type.

B] Een SSHD (Solid-State Hybrid Drive) is inderdaad een HDD (Hard Disk Drive) (niet HD = High Definition = wat anders), met een buffer, het zgn. "flash-geheugen."
In die buffer worden inderdaad de meest aangeroepen data geplaatst, ongeacht of deze data versleuteld is.
In deze situatie is de SSHD-controller (de chip die, o.a., bepaalt welke data in de buffer gezet moet worden) niet in staat om de data te ontsleutelen.
Wel filtert deze controller op zaken als archief- en mediabestanden, ongeacht of de data versleuteld is.
Dat kan doordat het daarbij om grote hoeveelheden data gaat, die relatief langzaam wordt aangeroepen, in tegenstelling tot OS-code bijvoorbeeld.
Noot: Er zijn wel harde schijven die dat versleutelen -hardwarematig- kunnen, maar dat doet hier verder niet ter zake (want je gebruikt een softwarematige oplossing = Northbridge).

C] Heb je nu een andere indruk?

D] Er is geen woord zo onlogisch als "logica."
1+1 = anything between 1 and 3.
(0.501) + (0.501) = (1.002) = (> 1)
(1.499) + (1.499) = (2.998) = (< 3)
Maar 1+1 zou ook exact 2 kunnen zijn natuurlijk.
En voor de gein maken we er dan 2x 1+1 = anything between 2 and 6 van. Logisch toch?

E] Akkoord, maar dan is het wel een beetje verwarrend dat je de termen zelf ook kris-kras door elkaar gebruikt. Zie kopje "B."

F] Ik kan oprecht zeggen, dat ik mijn best heb gedaan.
Mocht je nog vragen hebben, waar je niet via wikipedia aan uit komt, hoor ik het graag.

Verder leesmateriaal (Engels):
Moederbord - https://en.wikipedia.org/wiki/Motherboard

Relevant t.a.v. encryptie op schijf - https://en.wikipedia.org/wiki/Trusted_Platform_Module & http://www.howtogeek.com/237232/what-is-a-tpm-and-why-does-windows-need-one-for-disk-encryption


Kort samengevat; je aanname is niet correct.
Hier is toch echt wel over nagedacht door de fabrikanten en dus is er géén security-issue t.a.v. encryptie op de buffer van een SSHD, op de manier zoals jij omschrijft.


Andere overwegingen:
- Slaapstand (volledige inhoud RAM op schijf)
- Virtueel geheugen (gedeeltelijke inhoud RAM op schijf)
- Verschillen tussen PC en smartphone (onbereikbaar 2e OS (ROM) in chipset).

T.s.

Wow & kijk!

Hartelijk dank voor de uitgebreide antwoorden "12:39 door Erik van Straten" & "13:53 door Anoniem".

Het voorbeeld dat Erik aanhaalde was inderdaad bij wijze van hoe ik me dit voorstelde en me afvroeg of dat dan ook zo was. (Los van het feit of iemand er 'normaal gesproken' wel of niet bij kan, dat geldt immmers ook voor resterend rondzwervende data op een zogenaamd gewiste SSD-disk)

Het uitgebreid geïllustreerde antwoord van Anoniem 13:53 daarnaast leggende (wat een goed idee met die afbeelding erbij) is dat dus niet aan de hand begrijp ik nu (hopelijk goed) bij versleutelde bestanden op een versleutelde HD(;D , je "'cachte' de drift" gelukkig wel).

Goed om te weten dat deze combi-disks dan ook veiliger dan aangenomen zijn gebouwd, je ziet SSHD voor grote disk steeds meer waar grote SSD's onbetaalbaar zijn, en ik zag er namelijk geen info of discussies over dit SSHD 'security-opslag-fenomeen' (maar ik ken ook niet het hele internet en ben geen techneut).

Dus : ook bij gebruik van SSHD disks gevoelige data altijd versleutelen.

Nogmaals hartelijk dank voor de uitgebreide inzichtelijker antwoorden!

Super!

En daar wordt ik dan weer vrolijk van.
Ik heb de reactie van Erik van Straten net pas gezien (vanochtend een paar keer met tussenpozen aan die post gewerkt ivm andere bezigheden), maar het toeval wil, dat als je die uitgebreide, en goed weergegeven informatie over opslagmedia combineert, met wat ik schreef over hoe data verder wordt behandeld door het systeem, je een heel prachtig totaalplaatje krijgt. Top!

Ik wil nog wel even wijzen op de risico's van slaapstand icm softwarematige disk-encryptie; als je een programma gebruikt dat géén ondersteuning biedt voor TPM-chips (zie linkjes vorige post, TrueCrypt niet, MS Bitlocker wél), wordt de volledige inhoud van het RAM, onversleuteld op de systeemschijf geknikkerd bij het activeren van de slaapstand.

Nu kun je zelf waarschijnlijk wel inschatten wat voor risico dat kan opleveren.
En ook dat wordt vaak vergeten bij het gebruik van softwarematige disk-encryptie.

Dus; slaapstand niet gebruiken icm non-TPM FDE (Full Disk Encryption).


NB: Het virtueel geheugen (Swap-file) wordt wél versleuteld door iedere, mij bekende, FDE-oplossing.
Dat is dus géén risico, tenminste, voor zover ik me daarvan bewust ben.


Graag gedaan, en bedankt voor de feedback!

Gr 13:53

Dat is gelukkig onjuist. Om te beginnen zijn er minstens 2 soorten "slaapstand" (ik gebruik de termen uit mijn Engelstalige Windows):

1) "Sleep": informatie blijft in het geheugen van de PC, dat spanning blijft houden. Na "wakker maken" wordt niet om een TrueCrypt wachtwoord gevraagd, want dat staat nog gewoon in het geheugen. Ook een aanvaller hoeft dat wachtwoord dan niet in te vullen, mocht je jouw PC ergens hebben laten liggen of na diefstal in deze toestand. Als die risico's bestaan is het onverstandig om deze slaapstand te gebruiken. Persoonlijk gebruik ik de slaapstand als ik mijn notebook moet verplaatsen binnen een vertrouwd pand (bijv. naar een vergaderruimte).

2) "Hibernate": de inhoud van het geheugen wordt weggeschreven naar schijf, waarna de PC echt uit gaat. Na "wakker maken" wordt wel om een TrueCrypt wachtwoord gevraagd. Dat staat welliswaar ook in de hibernate file, maar om die te kunnen decrypten moet toch echt eerst de TrueCrypt driver geladen zijn en moet deze over het wachtwoord beschikken. Dit is net zo veilig als een volledige shutdown. Persoonlijk gebruik ik Hibernate nooit (doe altijd "Shut down"), omdat ik er de voorkeur aan geef om met "een schone lei" te beginnen en zeker wil weten dat eventuele updates geïnstalleerd worden.

Vrij vertaald uit de manual van TrueCrypt (een kopie vind je o.a. hier: http://andryou.com/truecrypt/docs/hibernation-file.php): als de hele schijf (FDE), of in elk geval de partitie waarop de hibernate file staat, versleuteld is met TrueCrypt versie 7.0 of later, wordt ook de hibernate file versleuteld weggeschreven.

Hartelijk bedankt voor de verbetering Erik, daar wordt ik vrolijk van!

Mijn post is gebaseerd op sterk verouderde informatie, die inmiddels (GELUKKIG) achterhaald is.
En al een tijdje ook ... 2008 ... *kuch*

Mijn post is gebaseerd op het feit dat, binnen één van de organisaties waar ik voor gewerkt heb, dit een groot issue is geweest.

Dat is destijds opgelost door (gefaseerd) hardwarematige encryptie in te voeren, zowel server-side als op end-points, met alle kosten (en problemen) van dien.
Daartoe is vooral besloten omdat alle beschikbare softwarematige FDE-oplossingen destijds, kwetsbaar bleken, aangezien MS de betreffende API nog niet had aangeboden aan ontwikkelaars.
Dat dat, lange tijd terug al, is rechtgezet door MS, is me volledig ontgaan.
Na de daarop volgende audit, heb ik me namelijk verder niet echt meer beziggehouden met het issue, zoveel mag duidelijk zijn.

Nogmaals, oprecht bedankt voor de verbetering!
Tevens ben ik blij dat MS de betreffende API heeft vrijgegeven, waardoor dit issue niet meer ter zake doet bij de huidige generatie MS-producten.


Voor de volledigheid:
Ik kom regelmatig bij bedrijven, instellingen en organisaties die nog steeds werken met (zwaar) verouderde systemen, zoals XP en 2003. Met name in de zorg, bij lokale overheden en binnen de semi-publieke sector.

Officieel is de Hibernate-API voor deze oude systemen (nog steeds) niet beschikbaar, in de praktijk is het natuurlijk vrijwel zeker, dat MS de oude API's niet gaat aanpassen, waardoor TC 7.0 ook voor deze systemen het probleem lijkt op te lossen.
TrueCrypt zelf echter, biedt (bood) geen garantie dat dat ook daadwerkelijk zo is.
Voor rechtspersonen die een bepaalde aansprakelijkheid 'genieten,' is het dus nog steeds onwenselijk, om deze oude systemen in de slaapstand te zetten icm softwarematige FDE-oplossingen.
Dat het onwenselijk is om verouderde systemen te blijven gebruiken, is een ander verhaal.

Conclusie: ik ben oud, grijs en niet goed wijs. Maar gelukkig nog niet te oud om wat bij te leren.


@alle lezers: Mijn excuses voor de foutieve, of in ieder geval zéér onvolledige, informatie.

Doe niet zo mal! Security heeft betrekking op zo ontzettend veel zaken dat het onmogelijk is voor 1 mens om alles te weten en bij te houden. Iedereen (zeker ook ik, naar beste eer en geweten), roept soms dingen die flauwe kul, totaal onjuist of achterhaald zijn.

Dat is de belangrijkste reden waarom ik hier bijdragen schrijf (om zelf bij te leren bedoel ik). Vóór gisteravond had ik met TrueCrypt nog nooit van hibernate gebruik gemaakt, maar schrok van jouw bijdrage en ben het meteen gaan uitzoeken. Et voilà...

En ook ik hoop natuurlijk dat anderen mij corrigeren als ik wartaal o.i.d. produceer... Bij voorbaat dank!

Je hebt natuurlijk gelijk Erik.
Mijn punt van schaamte; meestal doe ik eerst even een zoekopdrachtje, alvorens informatie op het web te knallen.
Niet alleen omdat ik dyslexie heb, maar zeker ook om me ervan te vergewissen dat de gegeven informatie nog steeds correct en actueel is.

Dat ik dat in dit geval, bijna 10 jaar lang, structureel verzuimd heb, vind ik een eye-opener.
("Hoeveel meer heb ik wel niet gemist?")
Vandaar mijn nederige reactie.


NB: Wel grappig om te lezen dat dit issue jou blijkbaar niet eerder ten gehore is gebracht, dat maakt het wel weer een beetje goed ;)

Precies,

Ondergetekende is zich op dit moment nog wild aan het zoeken hoe het werkelijk zit met je nuttige extra noot.

Voorlopige tussenstand :
- Mac's hadden/hebben wel/niet een TPM aan boord (kanteldatum 2006) en als ze hem hadden werd het niet hiervoor ingezet.
- Desktop Mac's hebben standaard hibernate uitgeschakeld als ze een tukkie gaan doen.
Macbooks daarentegen (!!) vallen er wel op terug als tijdens het slapen werkelijk het licht uitgaat (accu leeg).
- De optie om wel of geen gebruik te maken van hibernate valt voor Mac's wel te veranderen, ook nog zelfs juist wel activeren van hibernate in combinatie met leegmaken van het memory bijvoorbeeld.
Maar (!), onduidelijk is of dat geheel wegschrijven van de Ram op HDD bij Macbooks met ingeschakelde encryptie nou versleuteld of onversleuteld gebeurt.
Vind er (nog) geen (voldoende) documentatie over.

Mac en TPM, op zich een nieuw topic waard maar helaas een niveau van kennis van zaken vragende die nog wel wat studie vereist.
'ns kijken of ik een iets slimmer vervolgtopic over TPM en Mac kan insteken, zit er niet mee als een ander met meer grijze haren daar zijn licht over laat schijnen.

Zogenaamd 'domme' vragen, 'domme' vergissingen en 'domme' opmerkingen kunnen dus heel functioneel zijn heeft dit topic weer geleerd.

;)
T.s.

Joh, serieus?

Ik ga wel hard lachen als door een fout / achterstand van 10 jaar mijner zijde, jij iets zou gaan ontdekken dat op dit een moment een probleem zou kunnen vormen voor moderne systemen.
Ik verwacht overigens van niet hoor, vooral omdat Apple zelf FDE levert, en die Hibernate-code dus geen belemmering zou mogen vormen voor het correct implementeren van encryptie.
Daarnaast kijkt Apple vaak kwetsbaarheden van andere OS af, net zoals andere OS vaak kwetsbaarheden van Apple af kijkt.

Ik heb morgen een lunchdate met een dame die behoorlijk verstand van Mac (en Unix) heeft, ik zal eens vragen of zij er iets zinnigs over kan zeggen. Ik in ieder geval niet, sorry.

- Voor de duidelijkheid: ik neem aan dat je refereert aan FileVault 2?

Ook ik ben wel benieuwd nu, hopelijk heeft iemand een zinnig linkje ter Lering ende Vermaeck voor ons.


En ook jij hartelijk bedankt voor je positieve feedback op mijn knullige schrijfsel!

Helemaal vergeten te doen, sorry :(