243:
the authorized user). Usually this is no benefit to an unauthorised intruder, because they cannot access or use those keys—for example due to security built into the software or system. However, if the memory devices can be accessed outside the running system without loss of contents, for example by quickly restarting the computer or removing the devices to a different device, then the current contents—including any encryption keys in use—can be plainly read and used. This can be important if the system cannot be used to view, copy or access that data—for example the system is locked, or may have
154:
25:
359:
259:
could be accessed this way is vulnerable to such attacks. Usually a cold boot attack involves cooling memory chips or quickly restarting the computer, and exploiting the fact that data is not immediately lost (or not lost if power is very quickly restored) and the data that was held at the point of intervention will be left accessible to examination.
258:
Since this is a physical property of the hardware itself, and based on physical properties of memory devices, it cannot be defeated easily by pure software techniques, since all software running in memory at the point of intervention becomes accessible. As a result, any encryption software whose keys
242:
themselves used to read or write that data are usually stored on a temporary basis in physical memory, in a plain readable form. (Holding these keys in "plain" form during use is hard or impossible to avoid with usual systems since the system itself must be able to access the data when instructed by
262:
Cold boot attacks can therefore be a means of unauthorized data theft, loss or access. Such attacks can be nullified if the encryption keys are not accessible at a hardware level to an intruder–i.e., the devices in which the keys are stored when in use are not amenable to cold boot attacks–but this
449:
during software resets. The authors deem this an apparent flaw in many implementations of virtual machines, but note that virtual systems would be inherently vulnerable even if this were rectified, since all registers on a virtual machine are likely to be accessible using the host
610:"Beyond improving performance, the AES instructions provide important security benefits. By running in data-independent time and not using tables, they help in eliminating the major timing and cache-based attacks that threaten table-based software implementations of AES."
323:
registers which could in effect be made privileged by disabling all SSE instructions (and necessarily, any programs relying on them), and the debug registers which were much smaller but had no such issues. He left the latter for others to examine, and developed a
226:, are often unbreakable with current technology, so emphasis has moved to techniques that bypass this requirement, by exploiting aspects of data security where the encryption can be "broken" with much less effort, or else bypassed completely.
488:(the highest privilege level), bypassing the "lockout" imposed by TRESOR, which would allow it to read the keys from the debug registers and transfer them to usual memory. The paper also proposed ways to mitigate such attacks.
233:
is one such means by which an intruder can defeat encryption despite system security, if they can gain physical access to the running machine. It is premised on the physical properties of the circuitry within
434:
sleep and low power states: - on real processors registers are reset to zero during ACPI S3 states (suspend-to-ram) and S4 (suspend-to-disk) states since the CPU is switched off for these.
279:(the highest privilege level) only—the exception being the brief period of initial calculation at the start of a session. This ensures that encryption keys are almost never available to
408:
Although they cannot rule out CPU data leaking into RAM, they were unable to observe any case this happened during formal testing. Any such case is expected to be patchable.
58:
345:", and run slightly faster than standard encryption despite the need for key recalculation, a result which initially surprised the authors as well.
271:
TRESOR is a software approach that seeks to resolve this insecurity by storing and manipulating encryption keys almost exclusively on the
431:
330:
140:
Security 2011. The authors state that it allows RAM to be treated as untrusted from a security viewpoint without hindering the system.
133:
129:
437:
Cold boot attacks on the CPU: - on real processors registers are cleared to zero on both hardware resets and software resets ("
420:
315:
TRESOR was foreshadowed by a 2010 thesis by Tilo Muller which analyzed the cold boot attack issue. He concluded that modern
428:), if compiled to support these, but otherwise appears not to be accessible in any known way on a standard running system.
670:
524:"Crypto Talk at 27C3: FrozenCache – Mitigating cold-boot attacks for Full-Disk-Encryption software, Day 3, 23:00, Saal 2"
35:
201:
76:
183:
124:(RAM). It is one of two proposed solutions for general-purpose computers. The other, called "frozen cache" uses the
462:
44:
179:
548:
665:
238:
that are commonly used in computers. The concept is that when a computer system has encrypted data open, the
529:
342:
570:
485:
276:
320:
288:
660:
164:
54:
303:
272:
175:
168:
40:
608:: Shay Gueron, Intel Advanced Encryption Standard (AES) Instruction Set White Paper, Rev. 3.0:
415:
16:
Linux kernel patch which provides CPU-only based encryption to defend against cold boot attacks
296:
235:
121:
8:
458:
319:
processors had two register areas where CPU-based kernel encryption was realistic: the
292:
239:
223:
215:
93:
457:
and cache-based attacks by design of the AES-NI instruction, where the CPU supports
503:
325:
230:
113:
622:
96:
for "TRESOR Runs
Encryption Securely Outside RAM", and also the German word for a
523:
498:
442:
438:
219:
645:
380:
50:
461:
extensions. Processors capable of handling AES extensions as of 2011 are Intel
284:
654:
470:
454:
247:
or other intrusion controls, or is needed in a guaranteed untouched form for
484:
could break this system, by injecting code that would invisibly function at
414:
to the encryption keys via the kernel of a running system is possible using
222:
on a computer. Modern encryption algorithms, correctly implemented and with
466:
384:
117:
101:
341:, there is no performance penalty compared to a generic implementation of
474:
411:
337:
Its developers state that "running TRESOR on a 64-bit CPU that supports
481:
244:
105:
373:
299:
280:
125:
153:
24:
369:
252:
248:
218:, a common problem for data security is how an intruder can access
591:
571:"Cold-Boot Resistant Implementation of AES in the Linux Kernel"
338:
308:
137:
605:
283:
code or following a cold boot attack. TRESOR is written as a
445:, since they are reset during simulated hardware resets but
97:
547:
MĂĽller, Tilo; Freiling, Felix C.; Dewald, Andreas (2011).
316:
109:
441:"). However CPU registers are currently vulnerable on
546:
116:
on computer systems by performing encryption inside
652:
480:In 2012 a paper called TRESOR-HUNT showed how a
39:, potentially preventing the article from being
542:
540:
128:instead. It was developed from its predecessor
623:"TRESOR-HUNT: Attacking CPU-Bound Encryption"
592:"TRESOR Runs Encryption Securely Outside RAM"
549:"TRESOR Runs Encryption Securely Outside RAM"
537:
348:
312:access to the debug registers for security.
182:. Unsourced material may be challenged and
620:
59:reliable, independent, third-party sources
614:
521:
202:Learn how and when to remove this message
77:Learn how and when to remove this message
621:Blass, Erik-Oliver; Robertson, William.
404:The authors' paper notes the following:
53:by replacing them with more appropriate
509:
36:too closely associated with the subject
653:
568:
275:alone, and in registers accessible at
352:
266:
180:adding citations to reliable sources
147:
18:
469:(some i3 excepted) and successors,
291:that stores encryption keys in the
13:
334:based on the SSE register method.
14:
682:
639:
357:
152:
34:may rely excessively on sources
23:
598:
584:
562:
515:
372:format but may read better as
1:
143:
530:Chaos Communication Congress
7:
522:Erik Tews (December 2010).
492:
10:
687:
671:Computer security exploits
569:MĂĽller, Tilo (May 2010).
349:Potential vulnerabilities
306:, and blocking of usual
453:TRESOR is resistant to
424:) and physical memory (
416:loadable kernel modules
381:converting this section
263:is not the usual case.
136:2010 and presented at
104:patch which provides
666:Side-channel attacks
510:References and notes
328:distribution called
176:improve this section
122:random-access memory
459:AES instruction set
418:or virtual memory (
293:x86 debug registers
383:, if appropriate.
112:to defend against
604:The authors cite
402:
401:
267:TRESOR's approach
216:computer security
212:
211:
204:
114:cold boot attacks
94:recursive acronym
87:
86:
79:
678:
646:TRESOR home page
634:
633:
627:
618:
612:
602:
596:
595:
588:
582:
581:
575:
566:
560:
559:
553:
544:
535:
534:
519:
504:Secure by design
443:virtual machines
427:
423:
397:
394:
388:
379:You can help by
361:
360:
353:
326:proof of concept
311:
231:cold boot attack
224:strong passwords
207:
200:
196:
193:
187:
156:
148:
82:
75:
71:
68:
62:
27:
19:
686:
685:
681:
680:
679:
677:
676:
675:
661:Disk encryption
651:
650:
642:
637:
625:
619:
615:
603:
599:
590:
589:
585:
573:
567:
563:
551:
545:
538:
520:
516:
512:
499:Disk encryption
495:
439:Ctrl-Alt-Delete
425:
419:
398:
392:
389:
378:
362:
358:
351:
307:
269:
240:encryption keys
208:
197:
191:
188:
173:
157:
146:
132:, presented at
108:using only the
83:
72:
66:
63:
48:
28:
17:
12:
11:
5:
684:
674:
673:
668:
663:
649:
648:
641:
640:External links
638:
636:
635:
613:
597:
583:
561:
536:
513:
511:
508:
507:
506:
501:
494:
491:
490:
489:
478:
473:, and certain
455:timing attacks
451:
435:
429:
409:
400:
399:
365:
363:
356:
350:
347:
268:
265:
236:memory devices
220:encrypted data
210:
209:
192:September 2012
160:
158:
151:
145:
142:
85:
84:
31:
29:
22:
15:
9:
6:
4:
3:
2:
683:
672:
669:
667:
664:
662:
659:
658:
656:
647:
644:
643:
631:
624:
617:
611:
607:
601:
593:
587:
579:
572:
565:
557:
550:
543:
541:
532:
531:
525:
518:
514:
505:
502:
500:
497:
496:
487:
483:
479:
476:
472:
471:AMD Bulldozer
468:
464:
460:
456:
452:
448:
444:
440:
436:
433:
430:
422:
417:
413:
410:
407:
406:
405:
396:
387:is available.
386:
382:
376:
375:
371:
366:This section
364:
355:
354:
346:
344:
340:
335:
333:
332:
327:
322:
318:
313:
310:
305:
301:
298:
294:
290:
286:
282:
278:
274:
264:
260:
256:
254:
250:
246:
241:
237:
232:
227:
225:
221:
217:
206:
203:
195:
185:
181:
177:
171:
170:
166:
161:This section
159:
155:
150:
149:
141:
139:
135:
131:
127:
123:
119:
118:CPU registers
115:
111:
107:
103:
99:
95:
91:
81:
78:
70:
60:
56:
52:
46:
42:
38:
37:
32:This article
30:
26:
21:
20:
629:
616:
609:
600:
586:
577:
564:
555:
527:
517:
467:Sandy Bridge
446:
403:
390:
385:Editing help
367:
336:
329:
314:
302:generation,
270:
261:
257:
228:
213:
198:
189:
174:Please help
162:
120:rather than
102:Linux kernel
89:
88:
73:
64:
49:Please help
33:
477:processors.
475:VIA PadLock
412:Root access
295:, and uses
253:evidentiary
245:booby traps
655:Categories
630:ACSAC 2012
482:DMA attack
393:April 2022
297:on-the-fly
255:purposes.
144:Motivation
106:encryption
51:improve it
41:verifiable
421:/dev/kmem
304:atomicity
300:round key
281:userspace
163:does not
126:CPU cache
67:July 2014
55:citations
556:Preprint
493:See also
463:Westmere
426:/dev/mem
331:Paranoix
249:forensic
450:system.
287:to the
184:removed
169:sources
134:EuroSec
100:) is a
45:neutral
578:Thesis
486:ring 0
368:is in
339:AES-NI
309:ptrace
289:kernel
277:ring 0
138:USENIX
90:TRESOR
626:(PDF)
606:Intel
574:(PDF)
552:(PDF)
528:27th
374:prose
285:patch
130:AESSE
465:and
432:ACPI
370:list
167:any
165:cite
98:safe
43:and
447:not
343:AES
321:SSE
317:x86
273:CPU
251:or
214:In
178:by
110:CPU
57:to
657::
628:.
576:.
554:.
539:^
526:.
229:A
632:.
594:.
580:.
558:.
533:.
395:)
391:(
377:.
205:)
199:(
194:)
190:(
186:.
172:.
92:(
80:)
74:(
69:)
65:(
61:.
47:.
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
