HyperIO: A Hypervisor-Based Framework for Secure IO

Round 1

Reviewer 1 Report

The paper presents an interesting solution for the secure path between input and output devices. The proposed approach was applied in two forms: as FireSafe – a Firefox web browser extension and ClipCrypt – an application dedicated for the Windows users. The issue regarding secure communication with IO devices undertaken by the Authors is nowadays very important, demanding and challenging. The proposed thin hypervisor “HyperIO” seems to be an interesting answer to the needs in this area.

The paper is technically sound and describes comprehensively the aim, the contributions and the obtained results. The paper provides sufficient background and is written on a good level. Moreover, Authors discussed the proposed approach in three perspectives: security, convenience, and performance.

However, there are some minor mistakes which should be corrected:

1)      line 1, “Firefox” should be written with first capital letter,

2)      line 1, there is “extention” and should be “extension”,

3)      line 2, there is “passords” and should be “passwords”,

4)      line 7, there is a duplicated sentence “We propose… device drivers.”,

5)      line 9, there is “ClipCript” and should be “ClipCrypt”,

6)      line 130, the structure of the paper should be revised; the Section 3 is too short (only 4 lines), maybe it should be a subsection of Section 2 or 4; moreover, there is no need to write the title (“Threat model”) with capital letters,

7)      line 346, there is “per cent” and should be “percent”,

8)      line 494, there is “clipCrypt” and should be “ClipCrypt”.

Moreover, I suggest adding some figures (pictures, diagrams, screenshots etc.) to make the paper more readable and “user-friendly”. For example, a description of the communication between Alice and Bob described in Section 7.2 could be illustrated by the appropriate diagram. Similar could be done for the description of FireSafe behavior in Section 7.1.

Author Response

Thanks for your valuable review!
Additions (not typos etc.) are marked in red.

The paper presents an interesting solution for the secure path between input and output devices. The proposed approach was applied in two forms: as FireSafe – a Firefox web browser extension and ClipCrypt – an application dedicated for the Windows users. The issue regarding secure communication with IO devices undertaken by the Authors is nowadays very important, demanding and challenging. The proposed thin hypervisor “HyperIO” seems to be an interesting answer to the needs in this area.

The paper is technically sound and describes comprehensively the aim, the contributions and the obtained results. The paper provides sufficient background and is written on a good level. Moreover, Authors discussed the proposed approach in three perspectives: security, convenience, and performance.

However, there are some minor mistakes which should be corrected:

1)      line 1, “Firefox” should be written with first capital letter,

fixed

2)      line 1, there is “extention” and should be “extension”,

fixed

3)      line 2, there is “passords” and should be “passwords”,

fixed

4)      line 7, there is a duplicated sentence “We propose… device drivers.”,

fixed

5)      line 9, there is “ClipCript” and should be “ClipCrypt”,

fixed

6)      line 130, the structure of the paper should be revised; the Section 3 is too short (only 4 lines), maybe it should be a subsection of Section 2 or 4; moreover, there is no need to write the title (“Threat model”) with capital letters,

fixed

7)      line 346, there is “per cent” and should be “percent”,

fixed

8)      line 494, there is “clipCrypt” and should be “ClipCrypt”.

fixed

Moreover, I suggest adding some figures (pictures, diagrams, screenshots etc.) to make the paper more readable and “user-friendly”. For example, a description of the communication between Alice and Bob described in Section 7.2 could be illustrated by the appropriate diagram. Similar could be done for the description of FireSafe behavior in Section 7.1.

We have added 3 figures (Figures 2, 3, 4) to visualize the description

Nezer and Michael

Reviewer 2 Report

1.      The author proposed a theoretical Hypervisor framework to enhance the security of I/O devices. They also considered partial implementation of device drivers. The authors further proposed a system design and a comparison table of the proposed solution with the existing literature. However, the novelty is missing from the framework. 

2.      The entire Hypervisor framework and its system design are theoretically proposed. The authors must showcase a design flowchart of the proposed framework including all the steps for clarity.

3.      It is not clear from section 4, how the information is encrypted and decrypted, although they addressed public key cryptography. How do Requestor and Hyper IO have access to their public keys, where all the keys are stored, how Hyper IO gets a signal of false certificate/Requester, if any, what information is included in the certificate, and who checks the authority of these certificates, etc?

4.      In section 4.1, the authors mentioned that the HyperIO saves its private key in a secure memory region. How do we ensure that which part of the memory region is secure? The authors are suggested to provide an example of how PCR registers are used to protect the private key of HyperIO. How authors considered the distribution of public keys of HyperIO.

5.      The authors considered many assumptions for the framework without reasoning. Valid reasoning should be given for all the assumptions.

6.      Please check Table 1 as they mentioned for the proposed framework, partial drivers are considered, however, it is not mentioned in Table 1. Also, there is no sufficient research gap addressed between SGXIO and HyperIO.

 

7.      The demonstrations using the proposed framework are also not convincing and provide a theoretical background. 

Author Response

1. Thanks for your valuable review.
2. Major additions are now marked in red.
   
   
3. The author proposed a theoretical Hypervisor framework to enhance the security of I/O devices. They also considered partial implementation of device drivers. The authors further proposed a system design and a comparison table of the proposed solution with the existing literature. However, the novelty is missing from the framework. 
   
   The novelty is clearly marked in red.
4. The entire Hypervisor framework and its system design are theoretically proposed. The authors must showcase a design flowchart of the proposed framework including all the steps for clarity.
   We have added a figure (Figure 1) that depicts the design of HyperIO.
5. It is not clear from section 4, how the information is encrypted and decrypted, although they addressed public key cryptography. How do Requestor and Hyper IO have access to their public keys, where all the keys are stored, how Hyper IO gets a signal of false certificate/Requester, if any, what information is included in the certificate, and who checks the authority of these certificates, etc?
   We have added a subsection that explains which certificates are used by HyperIO. In addition we have added a section that provides a detailed description of the encryption/decryption steps.
6. In section 4.1, the authors mentioned that the HyperIO saves its private key in a secure memory region. How do we ensure that which part of the memory region is secure? The authors are suggested to provide an example of how PCR registers are used to protect the private key of HyperIO. How authors considered the distribution of public keys of HyperIO.
   We have added 2 paragraphs to address the raised questions. Subsection "TPM" in the "Background" section how the PCR registers protect the information stored in the TPM (HyperIO's private key, in our case). Subsection "System Architecture" of the "Seystem Design" section explains how the secure memory region is allocated and protected.
7. The authors considered many assumptions for the framework without reasoning. Valid reasoning should be given for all the assumptions.
   We did not change the assumption but added a paragraph with reasoning.
8. Please check Table 1 as they mentioned for the proposed framework, partial drivers are considered, however, it is not mentioned in Table 1. Also, there is no sufficient research gap addressed between SGXIO and HyperIO.
   We add short paragraph about SGXIO
9. The demonstrations using the proposed framework are also not convincing and provide a theoretical background. 
   We add a short paragraph explaining the demonstration
   
   Nezer & Michael

Round 2

Reviewer 2 Report

The suggested changes are reflected in the report with proper reasoning. The authors are advised to go through the manuscript again to check the English grammar and sentences used before the final submission.