|
Size: 1741
Comment:
|
Size: 2047
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Some of the security exploits I read about add additional bytes of malware onto innocent messages. |
= Byte Counting = === Counting interface and CPU operations to detect malware === -------- |
| Line 4: | Line 5: |
| It is quite cheap to add read-only physical counters to hardware interfaces, and count every operation of every variety that every interface does. |
Some of the security exploits I read about add additional bytes of malware onto innocent messages. |
| Line 8: | Line 7: |
| Hardware can copy the counters to more registers at the start and end of an operation, then compare what the interface does with what it is supposed to do - discrepancies may be merely a flaw in understanding - which should be dispelled during code design, Or it may indicate that something shady is going on. The counters can be available to multiple otherwise-firewalled processes, useful for white-hat traffic analysis without revealing exactly what is said to whom. |
It is quite cheap to add read-only physical counters to hardware interfaces, and count every operation of every variety that every interface does. If the counters are rarely read, they can be accessed via an on-chip multiplexed serial bus, minimizing the hardware and power cost of reading them. |
| Line 17: | Line 9: |
| The counters can be turned off and zeroed, and such operations can themselves be counted in hardware. Perhaps this can leak information to an adversary, but not much information of the code is designed right. This would be a tool to design such code. Counter visibility can also be disabled until the next reset. |
Hardware can copy the counters to more registers at the start and end of an operation, then compare what the interface does with what it is supposed to do - discrepancies may be merely a flaw in understanding - which should be detected and eliminated during code design. Or an unexpected count difference may indicate that something shady is going on. The counters can be available to multiple otherwise-firewalled processes, useful for white-hat traffic analysis without revealing exactly what is said to whom. |
| Line 23: | Line 11: |
| Hardware can also have flaws, of course, but such flaws are difficult to inject with runtime malware. Flaws injected during design and manufacturing are possible, but they are copied by the thousands and millions, and "hold still" for reverse engineering and comparison to gate level specification. |
The counters can be turned off and zeroed, and such operations can themselves be counted in hardware. Perhaps this can leak information to an adversary, but not much information if the code is designed correctly. This would also be a tool to design such code. Counter visibility should also have an "off" switch, so it is disabled until the next reset. |
| Line 29: | Line 13: |
| There are subtle ways to inject flaws at the transistor level if you can predict the supply chain and who gets which physical component, but that is very expensive compared to the usual "all parts alike" manufacture and test process. |
Hardware can also have flaws, of course, but such flaws are difficult to inject with runtime malware. Flaws injected during design and manufacturing are possible, but they are copied by the thousands and millions, and "hold still" for reverse engineering and comparison to gate level specification. |
| Line 34: | Line 15: |
| After some elaboration and development, I hope server sky components will have such counting capabilities to help with security. |
There are subtle ways to inject flaws at the transistor level if you can predict the supply chain and who gets which physical component, but that is very expensive compared to the usual "all parts alike" manufacture and test process. After some elaboration and development, I hope server sky components will have such counting capabilities to help with security. |
Byte Counting
Counting interface and CPU operations to detect malware
Some of the security exploits I read about add additional bytes of malware onto innocent messages.
It is quite cheap to add read-only physical counters to hardware interfaces, and count every operation of every variety that every interface does. If the counters are rarely read, they can be accessed via an on-chip multiplexed serial bus, minimizing the hardware and power cost of reading them.
Hardware can copy the counters to more registers at the start and end of an operation, then compare what the interface does with what it is supposed to do - discrepancies may be merely a flaw in understanding - which should be detected and eliminated during code design. Or an unexpected count difference may indicate that something shady is going on. The counters can be available to multiple otherwise-firewalled processes, useful for white-hat traffic analysis without revealing exactly what is said to whom.
The counters can be turned off and zeroed, and such operations can themselves be counted in hardware. Perhaps this can leak information to an adversary, but not much information if the code is designed correctly. This would also be a tool to design such code. Counter visibility should also have an "off" switch, so it is disabled until the next reset.
Hardware can also have flaws, of course, but such flaws are difficult to inject with runtime malware. Flaws injected during design and manufacturing are possible, but they are copied by the thousands and millions, and "hold still" for reverse engineering and comparison to gate level specification.
There are subtle ways to inject flaws at the transistor level if you can predict the supply chain and who gets which physical component, but that is very expensive compared to the usual "all parts alike" manufacture and test process.
After some elaboration and development, I hope server sky components will have such counting capabilities to help with security.