Guided Tour of the Precursor Motherboard

We talk a lot about “verifiable hardware”, but it’s hard to verify something when you don’t know what you’re looking at. This post takes a stab at explaining the major features of the Precursor motherboard by first indicating the location of physical components, then by briefly discussing the rationale behind their curation.

Above is a photo of a pre-production version of Precursor, annotated with the location of key components. Like software, hardware has revisions too. So, when verifying a system, be sure to check the revision of the board first. The final production units will have a clear revision code printed on the back side of every board and we’ll tell you where to look for the code once the location is finalized. There will be a few changes to the board before production, which we’ll talk about later on.

But what do all the components do, and how are they connected? Above is a block diagram that tries to capture the relationship between all the components.

Trusted and Untrusted Domains

First and foremost, you’ll notice that the design is split into two major domains: the “T-domain” and the “U-domain”. “T” stands for “Trusted”; “U” stands for “Untrusted”. A simplified diagram like this helps to analyze the security of the system, as it clearly illustrates what goes into and out of the T-domain; in other words, it defines the hardware attack surface of the trusted domain. Of course, not shown explicitly on the diagram are the side-channels, such as RF emissions and power fluctuations, which can be used to exfiltrate secret data. Very briefly, RF emissions are mitigated by enclosing the entire T-domain in a Faraday cage. Meanwhile, power fluctuations are mitigated partially through local filtering and partially through the use of constant-time algorithms to perform sensitive computations.

As the “Trusted” name implies, the T-domain is where the secrets go, while the U-domain acts as a first-level firewall to the untrusted Internet. The U-domain is explicitly designed for very low power consumption, so that it can be “always on” while still providing several days of standby time. We refer to the FPGA inside the U domain as the Embedded Controller (EC), and the FPGA inside the T-domain as the System on Chip (SoC) or sometimes simply as “the FPGA”.

Power Management and the Embedded Controller (EC)

The intention is that the always-on EC listens for incoming wifi packets; only once a valid packet is received will the T-domain be powered on.

Using a low-power EC separate from the SoC allows power-hungry processing to be done in bursts, after which the T-domain powers itself off. Thanks to the “memory LCD” that we have chosen, the display can appear persistently even when the T-domain is powered down. Of course, leaving data on the screen while the T-domain is powered down is a potential security risk, but users can adjust the power policy to trade off between security and battery life based on their particular use case and threat scenario. We anticipate that the T-domain running full bore with no power management would exhaust an 1100 mAh battery in about 6-7 hours. Any time spent in an idle state will greatly extend the battery life; thus for a hypothetical messaging application where the CPU is only active during periods of typing and data transfer, one should be able to achieve a full day of use on a single charge.

Mapping the T-Domain Attack Surface

Extending the boundary of trust to include human-facing I/O is a core tenet of the Precursor secure design philosophy. Thus, the T domain also includes the keyboard, LCD, and audio elements. This is because deferring the rendering of messages to an untrusted display means that any cryptography used to secure messages can be trivially defeated by a screen scraper. Delegating keystrokes to an untrusted touch controller likewise offers a quick work-around for capturing outgoing secrets through a keyboard logger. To mitigate/prevent this, Precursor incorporates an LCD that can be verified with an optical microscope and a physical keyboard that is trivial to verify with the naked eye. Precursor also forgoes an integrated microphone and instead favors a 3.5mm headphone jack, thus putting users solidly in control of when the device may or may not have the ability to record a conversation.

The green boxes in the block diagram above are connectors. These are items that plug into components that are not integrated into the mainboard. With this in mind, we can define the attack surface of the T-domain. We can see that we expose GPIO, USB, and JTAG to external connectors. We also have a bus to the U-domain that we call the COM bus, as well as a pair of quasi-static pins to communicate power state information and a set of pins to monitor the keyboard for user wake up events. Let’s explore each of these attack surfaces in a little more detail.

  1. JTAG A user is required to glue shut the JTAG port when the system needs to be sealed and secrets made inaccessible. This is done by placing a metal shield can over the T-domain and dabbing a specially formulated epoxy into the holes. This simultaneously completes the Faraday cage which reduces side band emissions while making the JTAG port more difficult to access.
  2. GPIOs and USB In its default configuration, the GPIOs are inert, and thus a difficult attack surface. We also advocate leaving the USB pins disconnected for secure applications; however, developers may opt to wire them up inside the FPGA, at the risk of opening up the expansive USB attack surface.
  3. Raw Power Input The primary postulated attack surface resulting from the raw power input are glitches. Denial of service is of course also an issue, by removing power or by destroying the system by applying too high a voltage; but these are beyond the scope of this discussion. The primary countermeasure against raw power input glitches is a reset monitor that will extend any glitch into a several-millisecond long reset signal if the voltage drops below a prescribed level. Furthermore, local filtering, regulation and power storage removes very short glitches. All T-domain power signals are routed so they are fully contained within the T-domain shield can. No T-domain power signals are exposed as outer-layer traces or vias on either the top or back side of the PCB outside of the T-domain shield.
  4. Power State Pins The power state pins allow the EC to coordinate with the FPGA SoC on the current power state. They are structured as “read only” from the SoC, and are also considered to be “advisory”. In other words, the SoC is capable of independently forcing its own power into the on-state; therefore the EC is only able to shut down power to the SoC when it is explicitly allowed by the T-domain. This minimizes the risk of the EC attempting to perform a glitch attack against the SoC by manipulating its access to power.
  5. Keyboard Wakeup Pins In order for the EC to know when to power on the system, the EC also has access to a pair of row/column pins on the keyboard matrix. This enables the EC to respond to a two-key chord to wake the system from sleep; however, it also means the EC can potentially monitor a few keys on the keyboard, leading to a potential information leakage. This is mitigated by a set of hardware isolation switches which the SoC uses to deny EC access to the keyboard matrix once the system is powered on.
  6. Audio is rendered by way of a CODEC chip. The DVT prototype shown in the photo above uses the LM49352, but a few months ago it was announced to be end-of-life by the vendor, TI. For production, we plan on employing the TLV320AIC3100, a functionally equivalent CODEC which will hopefully have a longer production lifetime. The CODEC chip integrates all the circuitry necessary to amplify the microphone, drive a pair of headphones, and also drive a small speaker for notifications. While it is possible to bury implants within the audio chip, it’s thought that any implant large enough to either record a useful amount of conversation or to do speech-to-text processing of the conversation would create an easily detectable size or power signature, or both. The headphone jack is wired for optimum compatibility with headsets from the Android ecosystem.
  7. COM bus Finally, the COM bus is an SPI interface used by the T-domain to talk to the rest of the world. It is directly connected to the EC. The COM bus is structured so that the SoC is the sole controller of the SPI bus; the EC is not able to send data to the SoC unless the SoC allows it. Further packet-level and protocol-level countermeasures are required on the COM bus to harden its attack surface, but at the end of the day, this is the primary pathway for data to reach the T-domain from the outside world, and therefore it should be the primary focus of any software-oriented attack surface analysis.

It is important that COM bus packets be authenticated, encrypted, and serialized prior to hand-off to the EC; the EC can only put T domain data into the appropriate envelopes for routing on the Internet and no more. This allows us to safely delegate to the EC the job of mapping COM bus packets onto a given network interface.

COM Connects to the Internet

Secure software running on the T-domain should be as oblivious as practical as to what type of Internet connection is implemented by the EC. Thus whether the EC routes COM packets to wifi, LTE, bluetooth, or Ethernet should have no bearing on the security of the T-domain.

For Precursor, we have chosen to add a Silicon Labs WF200 wifi chip to the EC as a primary means of Internet connectivity. The Silicon Labs WF200 contains a substantial amount of un-trustable code and circuitry; however, because the WF200 is in the Untrusted domain, we have no need to trust it, just as we have no need to trust the cable modem or the core network routers on the Internet.

Thus we can safely leverage the substantial co-processing within the WF200 to handle the complications of associating with WAPs, as well as other MAC/PHY-level nuances of wireless Ethernet. This allows us to substantially reduce the power requirements for the system during “screen off” time when it is mainly waiting to receive incoming messages. Furthermore, the WF200 has a well-characterized low power mode which agrees well with bench measurements. This is different from the ESP32, which as of a year ago when the evaluation was done, advertises low power but suffers from power-state transition nuances that prevent a practical system from achieving overall low power consumption.

The EC takes care of uploading firmware to the WF200, as well as servicing its interrupts and transcribing received packets to the T-domain. In addition to these responsibilities, the EC can detect if the system has been physically moved during standby by polling an IMU, and it also manages the battery charger and gas gauge. It also provides a ~1Hz square wave to the LCD that is required by the LCD during standby to continue displaying messages properly.

Random Number Generators

The T-domain includes a discrete TRNG. This is meant to complement a TRNG integrated into the SoC itself. The benefit of a discrete TRNG is that it can be verified using common lab equipment, such as an oscilloscope; the drawback of a discrete TRNG is that an attacker with physical possession of the device could manipulate its output by drilling through the RF shield and dropping a needle onto millimeter-scale component pads.

The integrated TRNG inside the SoC is less vulnerable to attack by a physically present attacker, but at the expense of being difficult to manually verify. Thus, we provision both discrete and integrated TRNGs, and recommend that developers combine their outputs prior to use in secure applications.

Keeping Time

A sense of time is important in many cryptographic protocols, thus a Real Time Clock (RTC) is a security-critical element. We chose an RTC that integrates both the crystal and the clock chip into a single hermetically sealed package to reduce the attack surface available to a physically present attacker to manipulate time. The chosen RTC also incorporates basic clock integrity checking, which helps to mitigate simple glitch attacks against the RTC.

RAM: Why 16MiB?

We provide 16MiB of battery-backed SRAM for secure computations. We made it battery-backed so as to reduce the standby/resume overhead of the system, at the expense of creating a potential attack surface for physically present attackers to recover data from the system.

The choice of 16MiB of SRAM was deliberate and motivated by several factors:

  1. Power A larger DRAM would have required using the DRAM PHY on the SoC. This interface is extremely power hungry and would have more than doubled the amount of power consumed when the system is on. Furthermore, keeping the DRAM in self-refresh mode would disallow powering down the FPGA entirely, meaning that the substantial standby leakage power of the SoC would count against the “screen-off” time.
  2. Code complexity Precursor is a spin-off from the Betrusted project. One of Betrusted’s goals is to build a codebase that could be audited by an individual or small group within a reasonable amount of time. Choosing a small amount of RAM is the equivalent of burning the boats before a battle to force an advancing army into a win-or-die situation; it confines every choice made in the OS and application layers to prefer simpler, less complex implementations at the expense of more development time and fewer features.
  3. Roadmap Eventually, we would like to fit the entire T-domain of Precursor into the footprint of a single chip. Incorporating hundreds of megabytes of RAM on-chip is impractical, even in aggressive process nodes. In a more realistic 28 or 40nm node, we estimate 4-16MiB is a potentially practical amount of RAM to incorporate in a low-cost, low-power, mass-market implementation. Provisioning Precursor with a similar amount of RAM helps to ensure code developed for it will have a migration path to more highly integrated solutions down the road.

Self-Destruct Mode

Finally, we have provisioned a “self-destruct” feature for users that opt to use battery-backed AES keys to protect their FPGA image. The “self-destruct” mechanism consists of a latch built using discrete transistors. During normal power-on, the system latches into a “normal” mode of operation. However, when the SoC asserts the “KEY_KILL” pin, the latch switches into the “kill” mode of operation. Once in the “kill” mode, power is cut to the T-domain – including the power that backs up the AES key. There is also a set active pull-downs which rapidly discharge the relevant voltage rails to ensure the power lines drop to a level suitable for data erasure in a matter of milliseconds. Although the data erasure only takes a fraction of a second, the only way to get out of “kill” mode is to remove the battery or to wait for the battery to fully discharge.

That wraps up our whirlwind tour of the Precursor motherboard. This post introduced all of the major design features of the Precursor motherboard and briefly summarized the rationale for each choice. The system architecture minimizes the attack surface of trusted components. Furthermore, component choice was guided by the principles of simplicity and transparency while trying to provide a complete but auditable solution for security-sensitive applications. Finally, the mainboard was designed with components only on one side, and all security-critical components are contained within a well defined area, with the hope that this makes it easier to visually inspect and verify units upon receipt by end users.

Liked this post? Sign up to the Precursor funding campaign mailing list to be notified when new posts go live!

13 Responses to “Guided Tour of the Precursor Motherboard”

  1. Brian Slesinsky says:

    re: “The headphone jack is wired for optimum compatibility with headsets from the Android ecosystem.”

    As someone who tinkers with audio projects now and then, I’m wondering what that entails? What should I be reading about?

  2. […] 我们讨论了很多有关“可验证的硬件”的问题,但是当您不知道所要查找的内容时,很难进行验证。这篇文章试图先解释物理组件的位置,然后简要讨论其策划背后的原理,以解释Precursor主板的主要功能。 上图是Precursor的预生产版本的照片,其中标注了关键组件的位置。像软件一样,硬件也有修订。因此,在验证系统时,请务必先检查主板的版本。最终生产单元的每个板背面都会印有清晰的修订代码,一旦位置确定,我们将告诉您在哪里可以找到该代码。电路板在生产前会有一些更改,我们将在后面讨论。 但是所有组件的作用是什么,它们如何连接?上面是一个试图捕获所有组件之间关系的框图。 受信任和不受信任的域 首先,您会注意到设计被分为两个主要域:“ T域”和“ U域”。 “ T”代表“受信任”; “ U”代表“不受信任”。这样的简化图有助于分析系统的安全性,因为它清楚地说明了进入和离开T域的内容。换句话说,它定义了受信任域的硬件攻击面。当然,图中未明确显示的是旁通道,例如RF发射和功率波动,可用于泄露机密数据。简而言之,通过将整个T域封装在法拉第笼中,可以减轻RF辐射。同时,功率波动部分通过局部滤波得到缓解,部分通过使用恒定时间算法执行敏感计算得到缓解。 顾名思义,“ T”域是秘密所在,而“ U”域则充当不可信Internet的第一级防火墙。 U域是为低功耗而专门设计的,因此它可以“始终打开”,同时仍提供数天的待机时间。我们将U域内的FPGA称为嵌入式控制器(EC),将T域内的FPGA称为片上系统(SoC),有时也简称为“ FPGA”。 电源管理和嵌入式控制器(EC) 目的是使永远在线的EC侦听传入的wifi数据包。仅在收到有效数据包后,T域才会上电。 使用与SoC分开的低功耗EC,可以快速进行耗电处理,然后T域自动关闭电源。由于我们选择了“内存LCD”,即使T域断电,该显示也可以持续显示。当然,在T域断电时将数据留在屏幕上是潜在的安全风险,但是用户可以根据自己的特定用例和威胁情况调整电源策略,以在安全性和电池寿命之间进行权衡。我们预计,在没有电源管理的情况下,全域运行的T域将在大约6至7个小时内耗尽1100 mAh电池的电量。在空闲状态下花费的任何时间都会大大延长电池寿命;因此,对于假设的消息传递应用程序,其中的CPU仅在键入和数据传输期间处于活动状态,因此一次充电就可以使用一整天。 映射T域攻击面 扩展信任范围以包括面向人的I / O是Precursor安全设计理念的核心租户。因此,T域也包括键盘,LCD和音频元素。这是因为将消息的呈现推迟到不可信的显示意味着用于保护消息的任何加密都可以被屏幕抓取器轻易地破坏。将击键委派给不受信任的触摸控制器,同样提供了一种快速解决方法,可以通过键盘记录器捕获传出的机密。为了减轻/防止这种情况,Precursor包含可以通过光学显微镜进行验证的LCD和可以通过肉眼进行验证的物理键盘。 Precursor还放弃了集成麦克风,而是采用3.5毫米耳机插孔,从而使用户能够牢牢控制设备何时可以录制对话或不录制对话。 上面框图中的绿色框是连接器。这些是插入未集成到主板的组件的项目。考虑到这一点,我们可以定义T域的攻击面。我们可以看到我们将GPIO,USB和JTAG暴露给外部连接器。我们还有一条通向U域的总线(称为COM总线),以及一对用于传递电源状态信息的准静态引脚,以及一组用于监视键盘上的用户唤醒事件的引脚。让我们更详细地探讨这些攻击面。 JTAG当系统需要密封且无法访问机密信息时,要求用户粘上JTAG端口。这是通过在T形区域上放置一个金属屏蔽罐并在孔中涂抹特殊配制的环氧树脂来完成的。同时完成了法拉第笼,可减少边带发射,同时使JTAG端口更难以接近。 GPIO和USB在其默认配置中,GPIO是惰性的,因此很难被攻击。我们还主张将USB引脚断开以确保安全应用。但是,开发人员可能会选择将它们连接到FPGA内部,从而有可能扩大USB攻击面。 原始功率输入原始功率输入产生的主要假定攻击面是毛刺。当然,通过断电或通过施加过高的电压来破坏系统,拒绝服务也是一个问题。但是这些不在本讨论的范围之内。防止原始电源输入毛刺的主要措施是复位监视器,如果电压下降到规定水平以下,该监视器将把任何毛刺扩展为几毫秒长的复位信号。此外,本地滤波,调节和功率存储消除了非常短的毛刺。所有T域电源信号都经过路由,因此它们完全包含在T域屏蔽罩中。 T区域屏蔽层外部的PCB顶部或背面,没有T区域电源信号作为外层走线或过孔暴露。 电源状态引脚电源状态引脚允许EC在当前电源状态下与FPGA SoC协调。它们在SoC中被构造为“只读”,也被视为“建议”。换句话说,SoC能够独立地强制其自身的电源进入导通状态。因此,EC仅在T域明确允许的情况下才能关闭SoC的电源。这样可以通过控制EC接通电源的方式将EC尝试对SoC进行故障攻击的风险降到最低。 键盘唤醒引脚为了让EC知道何时打开系统电源,EC还可以访问键盘矩阵上的一对行/列引脚。这使EC能够响应两键和弦以将系统从睡眠中唤醒;但是,这也意味着EC可能会监视键盘上的几个键,从而导致潜在的信息泄漏。一组硬件隔离开关可以缓解这种情况,一旦系统加电,SoC就会使用该隔离开关拒绝EC对键盘矩阵的访问。 音频通过CODEC芯片呈现。上图所示的DVT原型使用LM49352,但几个月前,供应商TI宣布将其淘汰。对于生产,我们计划使用TLV320AIC3100,它是功能等效的编解码器,有望延长生产寿命。 CODEC芯片集成了放大麦克风,驱动一副耳机以及驱动一个小的扬声器进行通知所需的所有电路。尽管可以将植入物掩埋在音频芯片中,但认为任何足够大的植入物可以记录有用的对话量或对对话进行语音到文本处理,都会产生易于检测的大小或功率签名,或者都。耳机插孔已布线,可与Android生态系统的耳机实现最佳兼容性。 COM总线最后,COM总线是T域用来与世界其他地方通信的SPI接口。它直接连接到EC。 COM总线的结构使得SoC是SPI总线的唯一控制器。除非SoC允许,否则EC无法将数据发送到SoC。在COM总线上,需要采取进一步的数据包级和协议级对策来强化其攻击面,但最终,这是数据从外界到达T域的主要途径,因此应该是任何面向软件的攻击面分析的主要重点。 在移交给EC之前,对COM总线数据包进行身份验证,加密和序列化非常重要; EC只能将T域数据放入适当的信封中以进行Internet路由,而不能再进行其他操作。这使我们可以安全地将EC总线数据包映射到给定网络接口上的工作委托给EC。 COM连接到Internet 在EC域实现哪种类型的Internet连接时,在T域上运行的安全软件应尽量避免使用。因此,EC是否将COM数据包路由到wifi,LTE,蓝牙或以太网都不会影响T域的安全性。 对于Precursor,我们选择在EC上添加Silicon Labs WF200 wifi芯片,作为Internet连接的主要手段。 Silicon Labs WF200包含大量不可信任的代码和电路;但是,由于WF200位于不受信任的域中,因此我们无需信任它,就像我们不需要信任Internet上的电缆调制解调器或核心网络路由器一样。 因此,我们可以安全地利用WF200内大量的协同处理来处理与WAP关联以及无线以太网的其他MAC / PHY级细微差别的复杂问题。这使我们能够在“屏幕关闭”时间内大幅减少系统的电源需求,该系统主要等待接收传入的消息。此外,WF200具有良好的低功耗模式,与台式测量非常吻合。这与ESP32有所不同,ESP32在一年前进行评估时,虽然宣称低功耗,但其功耗状态转换的细微差别使实用系统无法实现总体低功耗。 EC负责将固件上载到WF200,并处理其中断并将接收到的数据包转录到T域。除了这些职责外,EC可以通过轮询IMU来检测待机状态下系统是否已物理移动,并且还可以管理电池充电器和电量表。它还向LCD提供约1Hz的方波,这是待机期间LCD继续正常显示消息所需要的。 随机数发生器 T域包括离散的TRNG。这是为了补充集成到SoC本身的TRNG。离散TRNG的好处是可以使用普通的实验室设备(例如示波器)进行验证。离散式TRNG的缺点在于,拥有该设备的攻击者可以通过在RF屏蔽层上钻孔并把针头放到毫米级的元件焊盘上来操纵其输出。 SoC内集成的TRNG不太容易受到物理攻击者的攻击,但是以难以手动验证为代价。因此,我们同时提供了离散的和集成的TRNG,并建议开发人员在安全应用中使用之前合并其输出。 保持时间 时间感在许多密码协议中都很重要,因此实时时钟(RTC)是安全性至关重要的元素。我们选择了将晶体和时钟芯片都集成到单个密封封装中的RTC,以减少物理攻击者可以操纵时间的攻击面。所选的RTC还包含基本的时钟完整性检查,这有助于减轻针对RTC的简单故障攻击。 RAM:为什么选择16MiB? 我们提供16MiB电池供电的SRAM用于安全计算。我们以电池为后盾,以减少系统的待机/恢复开销,但以创建潜在的攻击面为代价,让物理上存在的攻击者从系统中恢复数据。 SRAM的16MiB的选择是经过深思熟虑的,并受到以下几个因素的推动: 电源使用SoC上的DRAM PHY可能需要更大的DRAM。该接口非常耗电,打开系统电源时消耗的电量将增加一倍以上。此外,将DRAM保持在自刷新模式将不允许整个FPGA掉电,这意味着SoC的大量待机泄漏功率将计入“关闭屏幕”时间。 代码复杂度Precursor是Betrusted项目的衍生产品。受信任的目标之一是建立一个可以在合理的时间内由个人或小组审核的代码库。选择少量的RAM等同于在一场战斗中将船只烧死,以迫使前进的军队陷入生死攸关的局面;它限制了OS和应用程序层中的每个选择,以更简单,不太复杂的实现方式为代价,但是却要花费更多的开发时间和更少的功能。 最终,我们希望使Precursor的整个T域适合单个芯片的占用空间。即使在激进的过程节点中,在芯片上集成数百MB的RAM也是不切实际的。在一个更现实的28或40nm节点中,我们估计4-16MiB是可以在低成本,低功耗,大众市场中实现的潜在实用数量的RAM。为Precursor配备相似数量的RAM有助于确保为其开发的代码将具有向更高集成度的解决方案迁移的途径。 自毁模式 最后,我们为选择使用电池后备AES密钥来保护其FPGA映像的用户提供了“自毁”功能。 “自毁”机制由使用分立晶体管构建的锁存器组成。在正常加电期间,系统会锁定为“正常”操作模式。但是,当SoC置位“ KEY_KILL”引脚时,锁存器切换到“ kill”操作模式。进入“ kill”模式后,电源将切断到T域–包括备份AES密钥的电源。还有一个设置的有源下拉电阻,可快速释放相关的电压轨,以确保电源线在几毫秒内下降到适合数据擦除的水平。尽管数据擦除只需要几分之一秒,但退出“终止”模式的唯一方法是取出电池或等待电池完全放电。 这结束了我们对Precursor主板的旋风之旅。这篇文章介绍了Precursor主板的所有主要设计功能,并简要总结了每种选择的原理。系统体系结构最大程度地减少了受信任组件的攻击面。此外,在尝试为安全性敏感的应用程序提供完整但可审核的解决方案时,组件的选择应遵循简单性和透明性的原则。最后,主板的设计仅在一侧提供了组件,并且所有对安全性至关重要的组件都包含在一个明确定义的区域内,希望这样可以使最终用户接收到的组件在视觉上更易于目视检查和验证。 喜欢这篇文章吗?订阅Precursor资金活动邮件列表,以便在新帖子发布时得到通知! 此条目发布于2020年9月25日(星期五)晚上10:32,并以受信任的Hacking,开源,前身文件形式提交。您可以通过RSS 2.0 feed跟踪对此条目的任何响应。 您可以在自己的网站上留下回应或引用。 Read More […]

  3. Fred says:

    Hmmm, I like the idea of isolated trusted and untrusted areas, faraday cages and epoxy to hide physical items – what great ideas that your opponents used back in the 50’s and 60’s and then went on to supersede.
    They simply understood the arena they were playing in & knew what and where ‘leaks’ occurred and designed there – otherwise your U & T areas are simply bypassed as you connect all your “trusted” and “”secure” information to bypass the isolation.
    I like the idea of FPGA although I would add it as a layer in depth.

    My thoughts for secure design are remember who makes the rules in the sand pit isn’t just who makes the sand pit – if you have to use the same sand …

  4. I’m curious what runtime environments you anticipate for the platform – I’m working on a metadata minimizing messenger system and am interested in writing a port that would work on this device, though 16MiB seems a bit tight given our choice of runtime (golang).

    I like that the system is implemented on a FPGA – that means a lot more flexibility than an ASIC for building custom HSM constructs for things like signal protocol ratchets.


  5. Andrew Pam says:

    “core tenant” is a typo for “core tenet”.

  6. Dave says:

    To deal with glitches, what about including enough capacitor storage to allow ride-through of a brief outage and a clean shutdown in case of a longer outage? Having a glitch force a reset seems like a way to enable at least some form of power-glitch attacks if you can force a reset with data in memory still intact. There’s an attack on, from memory, one of the STM32 family where you can recover data through a glitch-induced reset, which leaves data in memory, vs. a standard reset, which doesn’t.

  7. Robert Obryk says:

    Can the IMU be abused as a microphone? High sample rate accelerometers can serve as a poor microphone.

    • bunnie says:

      Theoretically, yes, but I suspect you’d have to be shouting directly at the device to get any SNR; furthermore, the practical sampling rate is limited by the speed of the I2C bus, which is quite slow. Probably the more realistic threat is some sort of an attack that analyzes the pauses between key presses to reduce the search space for brute-forcing passwords, as you could program the accelerometer to trigger on key presses using the IMU’s built-in tap detection filter. The countermeasure to that, if you’re very paranoid, is to turn on the buzzer motor with a randomized pattern of pulses whenever you’re typing in a password. That would likely make such attacks even more difficult.

  8. Nathan Myers says:

    We earlier discussed turning off (“holding in reset) the U part of the board while sensitive keypad input is going on. There was a wrinkle that the U part is responsible for stirring the LCD, so it would need to be woken once a second, and I suppose when a new digit is to be displayed, to do that.

    The threat is that the accelerometer could identify which key is pressed by the way pushing the button tilts the device, and maybe by the shock wave from the dome snapping reverberates around the device.

    We also talked about sending random keyclick noises to the speaker to inderfere with eavesdroppers.