Skip to content

InterviewScript.md

Latest commit

 

History

History
119 lines (71 loc) · 7.84 KB

InterviewScript.md

File metadata and controls

119 lines (71 loc) · 7.84 KB
Raw

Interview Script

Introduction. Thank you for agreeing to participate in this interview. We are currently conducting a research project on the firmware security of IoT devices. There are no right or wrong answers today; we simply hope to hear about your valuable experiences and perspectives from practical development work.

Please note that your participation is entirely voluntary, and you are free to skip any questions you prefer not to answer. To protect your privacy, we will not retain any audio or video recordings. Instead, we will rely solely on Tencent Meeting's real-time AI transcriptions, which will be manually stripped of any identifiable details (such as company names). All collected information will be kept in strict confidence and used exclusively for academic research purposes.

S1 Developer Profile & Context

  1. [Main Question] What is your current role at work?

    • What is the size of your team? What are the departmental divisions across the entire product development workflow within the company?

  2. [Main Question] What industries have your previous products focused on, and what major products have you developed?

    • Is the hardware platform primarily based on an MCU or a complex SoC running Linux or Android?
    • What is the typical lifespan of a product?

S2 Threat Perception & Knowledge

  1. [Main Question] In your industry community, what firmware security threats are people usually concerned about?

    • Have you ever encountered any security incidents in your professional practice?
    • If an attacker manages to extract the firmware, what specific harm do you think that would cause to your product and your business?

  2. [Main Question] If hackers attempt to extract the firmware, what methods do you think they are most likely to use? (Note: Let the interviewee speak first; follow up with the below questions to supplement after they finish.)

    • In your view, what are the primary threats when an attacker gains physical access to an IoT device?
    • Are you familiar with any more sophisticated firmware extraction techniques? How often do you consider these types of threats in your practical development work? (Prompt if hesitant: "For example, techniques like fault injection or side-channel attacks.")

  3. [Main Question] If you need to protect a firmware from extraction, what technical measures come to your mind first?

    • Do you understand the working principles behind these protection techniques?
    • When it comes to firmware protection, what is your perspective on using software approaches like obfuscation?

S3 Adoption of Protection Mechanisms

  1. [Main Question] Looking back to the products you have worked on that eventually went into mass production, which of them adopted firmware protection mechanisms, and which did not?

    Branch A: If firmware protection was not adopted

    • What were the main reasons for not enabling firmware protection at that time?
    • (If they hesitate or only give a surface-level answer, prompt them with neutral dimensions:)
      • [Product & Business] How did the product's positioning or overall value influence this decision?
      • [Technical & Schedule] What role did development timelines, hardware resources, or technical complexity play?

    Branch B: If firmware protection is adopted

    • What assets in the firmware did you think needed protection?
    • What specific measures have been implemented?
    • How are the encryption keys managed?

  2. [Main Question] In your company, who is responsible for deciding whether firmware should be protected?

    • Where do the initial requirements or driving forces for firmware security usually originate?
      • [Probe] e.g., external client/compliance demands vs. internal R&D initiatives.
    • How does your company allocate resources for firmware protection?
      • [Probe] What drives this allocation? How does security compete with other product features?

  3. [Main Question] Most MCUs come with three basic firmware protection options. The first one (L1) allows users to remove protection with a password. The second one (L2) requires full chip erasure to disable protection, such as the RDP1 in STM32 chips. The last one (L3) uses hardware fuses for permanent, irreversible locking, such as RDP2 in STM32. Have you had the chance to use any of these in practice?

    • Which type of protection does your team prefer to use, and what are the reasons behind this choice?
    • What factors or potential impacts do teams need to consider when adopting permanent hardware lock protection?

S4 Implementation Impacts

  1. [Main Question] In your opinion, what is the biggest non-technical barrier to the implementation of firmware protection, and what specific impacts has the enablement of firmware protection had on your project budget or timeline?

  2. [Main Question] Developers may not enable firmware protection even if the chips support it. Based on your experience, what is the biggest stumbling block? Please share the real barrier you have encountered in the following aspects:

    Scenario 1: R&D and Debugging (The "Inner Loop")

    • When firmware security protections are enabled, what extra steps are required after code changes? How do such measures affect build and flashing efficiency, and what impacts do they bring to developers' daily work practices?
    • If the code crashes but the debug interface is locked, how do you debug the problem?

    Scenario 2: Production and Yield (The Factory Floor)

    • What changes have taken place in production-line programming after deploying firmware security features?
    • What adjustments or equipment upgrades are needed in the factory to program encrypted firmware?
    • What issues have arisen from misconfigured firmware protection during chip programming?

    Scenario 3: After-Sales Service and Return Merchandise

    • Does firmware protection currently hinder your after-sales repair process? What specific challenges have you encountered?
    • If a returned device is permanently locked, what does your workflow look like for analyzing the root cause?

S5 Best Practices & Improvements

  1. [Main Question] What are your experiences with the security-related documentation and tools provided by chip manufacturers?

    • Where do you usually learn these security mechanisms from?
    • How would you perceive the clarity and accuracy of the technical documents? Have you encountered any challenges when using them, and in what ways could vendors improve these resources?

  2. [Main Question] Regarding development tools, how do you feel about the steps of enabling security features for firmware? Do you have any suggestions for improvement?

    • Could you describe how you currently enable security features? Specifically, does the process rely more on command-line interfaces, writing custom code, or automated "one-click" solutions? Furthermore, how would you describe the learning curve and the mental effort required to complete these steps?
    • When considering highly automated configuration tools, what are your thoughts on the balance between convenience, transparency, and the level of control you retain as a developer?

  3. [Main Question] What do you think could be done by your company, the industry, or regulators to encourage firmware protection and improve firmware security?

    • How would you describe the internal resources and technical support currently available for firmware security within your organization? Are there specific security baselines established?
    • What changes or support would you like to see from the industry or from policy makers?

Wrap Up

  1. [Main Question] Regarding firmware protection, is there any other experience, opinion or suggestion you would like to share