A Security Barrier Device protects PC and other control devices by relaying every port between the motherboard and the peripherals. The SBD is totally transparent from the PC and can be installed regardless of OS or application. At this presentation I will discuss the storage securing function achieved by the SBD relaying the SATA port. The SBD has a security information disk only accessible to itself where it stores the access privilege information of the original disk in the PC. When the PC issues a data access request to the original disk, the SBD will reference the access privileges of that particular sector, if the sector is read-deny then returns dummy data of 0 , if the sector is write-deny then it won’t write to that sector. The SBD not only allows for sector based protection but also a file based protection. In case of a file write-deny, there were some issues with the disc related cache in memory not being synchronised or the pointer’s position to the file in regards to its directory being shifted , but I will show how it was solved. I will also talk about the fact that a SBD is an effective protection against any malware that attempts to manipulate the boot data sector or system files, once it detects any access right violations it can shutdown the ethernet port remotely and thwart the spreading of malware. Kenji Toda At the National Institute of Advanced Industrial Science and Technology conducted research and development of 30 Gbps intrusion detection systems , 60 Gbps URL filtering systems and or network devices testing equipment for such systems. Currently co-developing security barrier devices with the Research and Development Control System Security Center. (Presented at international conferences regarding MST and real-time systems) http://codeblue.jp/en-speaker.html#KenjiToda

1. Security Barrier Device
Protects Critical Data Regardless of OS
and Applications by Just Attached
Kenji TODA, Ichiro EBIHARA, Koji SEGAWA,
Koichi TAKAHASHI and Kazukuni KOBARA
The National Institute of Advanced Industrial
Science and Technology (AIST)
in cooperation with
Control System Security Center (CSSC)

2. Contents
• Background
• Concept of SBD
• Data Protection Mechanism
• Hardware and Security Tag
• Sector Based Access Control
• File Based Access Control
• Malware Prevention
• Demonstration Video
• Future Work
Currently NTFS is implemented.
EXT and FAT are under development.
Applicable for other file systems.
2

3. Background:
PC and/or Server
• Hard to fix all the
vulnerabilities of complex
OS and applications.
• There exists undefended
period called zero-day
exposing unknown or
discovered-but-not-yet-
fixed vulnerabilities.
#Identified Vulnerabilities in a year
(http://www.symantec.com/ja/jp/threatreport/topic.jsp?id=vulnerability_trends&aid=
total_number_of_vulnerabilities)3

4. Background:
Control System
• Additional security software is not
affordable for restricted hardware
resources and / or realtime systems
• Outdated OS and applications might be
used without any security patch.
We develop SBD, the hardware solution of
easy attachable regardless of any OS and
applications without software installation.
4

5. SBD – Easy Attaching
Target
System
Just insert SBD between
IO Ports on the original hardware.
Protecting important data
regardless of OS and
applications.5

6. SBD:
Data Protection Mechanism
①The target system issues an
IO request to the original
HDD.
②SBD reads the security
information of corresponding
IO blocks.
③Data access is handled
according to the information
(permitted / inhibited /
queried) .
①
②
Added HDD:
Security Information
←Invisible from the System!
Original HDD:
Data
RW=10
③
Read〇
Write×
6

7. ＳＢＤ:
Full View
Security Barrier Device FPGA board developed for SBD
7

8. Security Barrier Device (SBD):
Board and Specifications
• Board size: PCI Express card (230mm x 110mm)
• FPGA chip： Xilinx Kintex-7 676pin XC7K325T
• Configuration Flush Rom: for power-on-write to FPGA
• Memory I/F: DDR3 SODIMM×1
• Display input: HDMI×1
• Display output: HDMI×1
• Optical audio: input×1, output×１
• Storage I/F： SATA (7pin)×5
• Ethernet I/F： 1G/100Mbit Ether (RJ-45) ×2
• USB I/F： USB (Type A)×6 (USB2.0)
• SBD host PC I/F： PCI Express×18

9. SBD Board Connections
SBD Control PC
SBD Board
Target Control Device
USB0
Ethernet (LAN)
HDMI
SATA0
PCIe
(card slot)
SATA1
USB1
SATA0
SATA1
USB0
USB1
HDMI
Ethernet
(LAN)
Peripherals of Target Control Device
9

10. Security Barrier Device (SBD):
Security Tags (sector based control)
Security Barrier Device (SBD)
Additional Storage for SBD Security
Target Control Device
User Login to
SBD
SBD PASSWORD FILE
USER
NAME
PASSWORD
(root)
UID
0
GID
SBD Control PC
(Linux kernel 2.6 or above)
SBD Board
OWNER GROUP OTHER
RqraWqra RqraWqra RqraWqraRqraWqra
UID GID
Original Storage of Target Control Device
SBD SECURITY TAGs for corresponding BLOCK
BLOCK
Original Data in Target Storage
USER
NAME
PASSWORD
UID
1
GID
Storage Access Storage Access
Additional Storage
Access
Loop Back
...
LoopBack / AccessControl:
{Query - assert / negate},
{Recording - all / no},
{Alert - no}
SBD SECURITY MODE
for storage access
(R: read, W: write, q: query, r: record, a: alert)
USB
USB
HDMI
SATA
PCIe
UID
SBD DEFAULT UID & GID
Ethernet
Loop Back
GID
• SATA Port Handling Logic is
implemented.
• Ethernet can be cut-off.
10

11. Security Barrier Device (SBD):
Sector Based Access Control
The target of storage access control is block devices
such as HDD / SSD / USB memory.
Since storage access is performed sector based
(512Byte unit),
implementation of sector based access control is
straightforward.
• Defense of disk regions and partitions is OK!
• Gathering to-be-write-protected data and system files
to write-protected partitions.
• Gathering to-be-read-protected data to read-protected
partitions.11

12. SBD: File Based Access Control
Motivation
File based access control extends defense coverage and
improves convenience dramatically:
• Critical system and user data is mostly files.
• No need to gather important files to protected partitions
• Original data disk can be protected as is.
• Easy assigning and releasing of protection on files.
• No stress on attaching and detaching of SBD (just plug
in/out IO connectors).
12

13. SBD: File Based Access Control
Requirements
Commonly-used file systems:
• NTFS (Windows, …）
• EXT(Linux, Android, …）
• FAT(old Windows, MS-DOS, VxWorks, USB memory,..）
• HFS+(Mac OS X,…)
Requirements to handle the above file systems:
• On access control of data blocks,
→〇 sector based control is appropriate;
→〇 read access control is appropriate;
→×write access control is NOT appropriate because pointers to
the data blocks may change their locations.
In non-resident data file and parent directories
13

14. SBD: File Based Access Control
Fine Grain Control
Protection is required on data of file and path from
the root.
Access granularity for directories and pointer areas
≦ sector size (512B)
1. Put access control granularity to the security information
corresponding to a sector.
2. In case of write to a sector, in addition to the security
information, the content of the sector is also read.
Then the write protected portion of the read data is used
instead of the sector data intended to write.
Consequently, fine grain control is achieved.14

15. Security Barrier Device (SBD):
File Read Protection (no difficulty)
In case SBD
returns zeroes for
read protected
data:
An error message
on opening
protected data on
a target system
(Ubuntu) →
15

16. SBD: Requirement for
Write Protection -- EXT2（Linux）
• /appdata/app_critical is a write protected file.
Path from the root directory needs protection.16

17. SBD: File Based Access Control
Remaining Difficulties
Problems of write protection on NTFS file:
① Inconsistency between disk-relating caches on the memory of a
defense target system and the disk may destroy file system and
cause OS crash.
② The locations of pointer entries relating the write protected file in its
parent directories may change by addition or deletion of other non-
protected files. Because, the location is rearranged by balanced
tree algorithm in NFTS. (←SBD achieves high performance by
means of FPGA circuit assuming fixed location.)
17

18. SBD: File Based Access Control
Disk-Relating OS Caches
[Problems] Linux (also Windows) utilizes following
caches for performance:
• Superblock (block group descriptor, bitmaps of free
block and free i-node, …)
• i-node cache
• Directory entry cache
• Buffer cache (for disk block data)
• Page cache (for file data)
Write inhibition on the disk causes
inconsistency between OS caches and the disk!18

19. SBD: File Based Access Control
Solution
Problems of write protection on NTFS file:
① Inconsistency between disk-relating caches on the memory of a
defense target system and a data disk may destroy file system and
cause OS crash.
② The locations of pointer entries relating the write protected file in its
parent directories may change by addition or deletion of other non-
protected files. Because, the location is rearranged by balanced
tree algorithm in NFTS. (←SBD achieves high performance by
means of FPGA circuit assuming fixed location.)
By observing OS
behavior using
SBD
→SBD makes the OS handle an accessed write-
protected file entry as a (pseudo) bad block by returning
a disk access error to the OS!
→The pointer location to its patent directory is never
changed as long as its directory pass is not changed!19

20. SBD: File Based Access Control
Write Protection Procedure
Write protection on NFTS file:
① In case of write, if rename or deletion is performed to the write
protected file, the operation is done on caches and appears
successful.
② In a short period, the contents of the caches are written to the disk,
then SBD detects it.
③ SBD returns a device error on the file access and issues an alert to
a user. OS handles the file entry as it is in a (pseudo) bad block.
(An Ethernet port can be shut-off by the alert as a trigger.)
① When a user reboots the OS, SBD restores the write protected files
in prior to OS booting. Hence, the OS can be booted as it was.
SBD makes write protection
consistent with the OS!
The pseudo bad blocks are restored from
$BadClus file.24

21. SBD: File Based Access Control
Mechanism
Security Barrier Device (SBD)
Additional Storage for SBD Security
Target Control Device
User Login to
SBD
SBD PASSWORD FILE
USER
NAME
PASSWORD
(root)
UID
0
GID
SBD Control PC
(Linux kernel 2.6 or above)
SBD Board
OWNER GROUP OTHER
RqraWqra RqraWqra RqraWqraRqraWqra
UID GID
Original Storage of Target Control Device
SBD SECURITY TAGs for corresponding BLOCK
BLOCK
Original Data in Target Storage
USER
NAME
PASSWORD
UID
1
GID
Storage Access Storage Access
Additional Storage
Access
Loop Back
...
LoopBack / AccessControl:
{Query - assert / negate},
{Recording - all / no},
{Alert - no}
SBD SECURITY MODE
for storage access
(R: read, W: write, q: query, r: record, a: alert)
USB
USB
HDMI
SATA
PCIe
UID
SBD DEFAULT UID & GID
Ethernet
Loop Back
GID
Detecting information is
prepared in prior to detection.
File system Dependent
Detection is
performed in fine
grain, byte unit,
by FPGA.
File system
Independent
25

22. ＳＢＤ：
Performance of Access Control
In case of fine grain, byte unit, detection (at high
overhead sate) = File based access control (read /
write) is enabled:
Experimentally 100MByte/s
Measuring Condition：
A original data disk and a security information disk:
Samsung SSD 830, 128GB
Benchmark Program:
Read-Only Benchmark, Ubuntu Disk Utility
Sector-wide comparator with byte unit mask circuit
+ Multi-sector IO buffer circuit
26

23. Security Barrier Device (SBD):
Malware Prevention
Protection by SBD：
• Bootkit
• Rootkit
27

24. 28
Bootkit:
Definition and Win32/Gapz
• The most dangerous infectious form bootkit launches before
Windows and hides in between hardware and OS. Hence, it
becomes undetectable and accesses system resources unlimitedly. 。
(technet.microsoft.com)
• Win32/Gapz: Advanced Evasion Techniques VBR infection type replaces
only a few bytes in BIOS Parameter Block. Hence, it is hard to detect.
(Evolved form of MBR infection type） (blog.eset-smart-security.jp)

25. 29
Bootkit
Win32/Gapz
MBR Infection type
• Fig shows the infection sequence of
MBR infection type （Traditional
Techniques）
① Bootkit code is loaded from disk,
Int 13h disk handler is hooked.
② ntldr, bootmgr, winload.exe and
loInitSystem are hooked in series,
kernel mode code (rootkit) is
launched.

26. 30
Bootkit
Win32/Gapz VBR
Infection type
• VBR Infection Type disk
image (Advanced techs)
① Hidden Sectors (4B) at
BIOS Parameter Block
in Volume Boot Record
is modified.
② Bootkit is launched
instead of IPL by mean
of skipping whole NTFS
volume in front of
bootkit

27. 31
Bootkit: ELAM
• ELAM（Early Launch Anti-Malware Module）, introduced in
Windows 8, does not work. (blog.eset-smart-security.jp)

28. 32
Bootkit
Win32/Gapz
• VBR Infection Type disk
image (Advanced techs)
① Hidden Sectors (4B) at
BIOS Parameter Block
in Volume Boot Record
is modified.
② Bootkit is launched
instead of IPL by mean
of skipping whole NTFS
volume before bootkit
③ The rest is the same as
MBR Infection type.
SBD protectable!

29. 34
Bootkit: Secure Boot
• On the secure boot, UEFI (Unified Extensible Firmware
Interface) verifies boot loader in advance of its loading. In case the
boot loader is modified or replaced (by bootkit), the secure boot
prevents its execution. (technet.microsoft.com, blogs.msdn.com)
The boot
loader code
itself is not
protected!
The boot loader
is stored in a
file for
verification!

30. 35
Bootkit: Secure Boot
• On the secure boot, UEFI (Unified Extensible Firmware
Interface) verifies boot loader in advance of its loading. In case the
boot loader is modified or replaced (by bootkit), the secure boot
prevents its execution. (technet.microsoft.com, blogs.msdn.com)
The boot
loader code
itself is not
protected!
The boot loader
is stored in a
file for
verification!
SBD protectable!

31. 36
Rootkit:
Definition and Sample
• Generic name of tool which invades and modifies computer
system with root (system manager) privilege (ASCII.jp)
• Typical rootkit hides Logon, Process, File and Log. It often
monitors input from network and/or keyboard. In many cases,
rootkit is also Trojan Horse. (Wikipedia)
• SONY BMG CD XCP case: It is audio player software with Copy
Guard function, on the side, access control (permitting outgoing
transmission and system invasion) using rootkit is installed. It
transmits data on computer and also prevents other media player
software from playing a music CD and/or copying to disk. Its
vulnerability was found and abused by malware. （→Currently,
Windows update has fixed it.） (Wikipedia)
System files
are modified!

32. 37
Rootkit:
Definition and Sample
• Generic name of tool which invades and modifies computer
system with root (system manager) privilege (ASCII.jp)
• Typical rootkit hides Logon, Process, File and Log. It often
monitors input from network and/or keyboard. In many cases,
rootkit is also Trojan Horse. (Wikipedia)
• SONY BMG CD XCP case: It is audio player software with Copy
Guard function, on the side, access control (permitting outgoing
transmission and system invasion) using rootkit is installed. It
transmits data on computer and also prevents other media player
software from playing a music CD and/or copying to disk. Its
vulnerability was found and abused by malware. （→Currently,
Windows update has fixed it.） (Wikipedia)
System files
are modified!SBD protectable!

33. SBD prevents write on boot area and shut-off
Ethernet, and stops Remote Control.
Attacker
Victim
Network is shut-off.
Defense by SBD
38

34. Future Work
• Feasibility study and
its feedback to SBD at
Control System Security
Center (CSSC)
• Linux EXT families and
widely-used FAT families are under development.
(Applicable for other file systems also.)
• Improvements on performance and robustness
• Tests using various malware
• Extension of SBD defense ability by developing
Ethernet, USB and HDMI port-supervisory circuit.
• Downsizing (such as a SBD storage)
39

35. FIN
40