diff options
Diffstat (limited to 'pelican/content')
24 files changed, 222 insertions, 405 deletions
diff --git a/pelican/content/AlphaBoardComponents.md b/pelican/content/AlphaBoardComponents.md index 2e005a0..39eb30e 100644 --- a/pelican/content/AlphaBoardComponents.md +++ b/pelican/content/AlphaBoardComponents.md @@ -3,27 +3,19 @@ Author: trac Date: 2016-12-15 22:43 # CrypTech Alpha Board BOM and PCB design requirement sketch -This document contains a list of component level description and requirements for the Crypteh Alpha board. - -The document is to be used as a BOM (Bill Of Materials) and PCB design requirement description for discussing with PCB designers on what we want to have designed. - +This document contains a list of component level description and requirements for the Crypteh Alpha board.<br/> +The document is to be used as a BOM (Bill Of Materials) and PCB design requirement description for discussing with PCB designers on what we want to have designed.<br/> The block diagram for the Alpha board can be seen at: [Hardware]({filename}Hardware.md) -The Alpha board basically consists of three major sub systems: - -1. **The FPGA Sub System** - - Used to implement CrypTech crypto/security cores accessible by the CPU as coprocessors. - - -2. **The CPU Sub System** +The Alpha board basically consists of three major sub systems:<br/> +1. **The FPGA Sub System**<br/> + Used to implement CrypTech crypto/security cores accessible by the CPU as coprocessors.<br/> +2. **The CPU Sub System**<br/> Talks to host systems and handles incoming commands. Basically implements the application interface. - Controls the FPGA Sub System. The CPU Sub System is heavily inspired/based on the CPU parts of the Novena and the iMX6 Rex boards. - - -3. **The Tamper Detect Sub System** + Controls the FPGA Sub System. The CPU Sub System is heavily inspired/based on the CPU parts of the Novena and the iMX6 Rex boards.<br/> +3. **The Tamper Detect Sub System**<br/> Responsible for implementing tamper detection and control/alarm as a separate functionality from the CPU. On the Alpha board this system is fairly simplistic. But we want to at least have a minor MCU that can run independently on battery power and control the Master Key Memory (MKM). detect external events and generate @@ -49,12 +41,8 @@ Joachim Strömbergson, Fredrik Thulin ### FPGA The board should be equipped with a Xilinx Artix-7 200T FPGA device, more specifically XC7A200T FBG484 speed grade -3. -* [Xilinx Artix-7 XC7A200T FBG484.](http://www.xilinx.com/products/silicon-devices/fpga/artix-7.html) - - - -* [Product family overview](http://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf) - +* [Xilinx Artix-7 XC7A200T FBG484.](http://www.xilinx.com/products/silicon-devices/fpga/artix-7.html)<br/> +* [Product family overview](http://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf)<br/> The FPGA pad layout should be compatible with the Xilinx Artix-7 FGG484 used by XC7A100T and XC7A75T. @@ -128,8 +116,7 @@ Suggested components for the MKM and the switch: * Memory: Microchip serial SRAM. 23A640, 8 kByte, 8-TSSOP or 8-SOIC -<http://ww1.microchip.com/downloads/en/DeviceDoc/22127a.pdf> - +<http://ww1.microchip.com/downloads/en/DeviceDoc/22127a.pdf><br/> * Quad 2-channel Analog Switch: ON Semi. MC14551B @@ -139,7 +126,7 @@ Suggested components for the MKM and the switch: ### Entropy Sources -* The avalanche noise entropy source should be implemented according to [existing schematics]({attach}AlphaBoardComponents/alpha_board_noise_source.pdf). +* The avalanche noise entropy source should be implemented according to [existing schematics]({attach}/AlphaBoardComponents/alpha_board_noise_source.pdf). * The noise source should have a shielding can and suitable ground plane etc. to keep radiation of entropy bits as low as possible. * The "12-15v stable" VCC should be controllable by the FPGA (enable/disable controlled by output pin on FPGA) to increase life time of components. Power requirements for this VCC is < 100 mA (needs measuring, but probably < 50 mA). @@ -196,13 +183,9 @@ The STM32 CPU supports two separate SDRAM banks. We use both of them with as big * Battery backed RTC with calendar/date information. Connected to the CPU via serial, SPI or other interface. * Suggested chip: Microchip MCP79411 or MCP79412 connected to the CPU via I2C. - <http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP79411> - - - <http://ww1.microchip.com/downloads/en/DeviceDoc/20002266G.pdf> - + <http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP79411><br/> + <http://ww1.microchip.com/downloads/en/DeviceDoc/20002266G.pdf><br/> This chip requires an external 32 kHz crystal. - * Note: these chips contain per chip unique IDs as well as small EEPROM memory that can be memory protected. diff --git a/pelican/content/AlphaBoardPictures.md b/pelican/content/AlphaBoardPictures.md index bc4b486..41fe3f6 100644 --- a/pelican/content/AlphaBoardPictures.md +++ b/pelican/content/AlphaBoardPictures.md @@ -13,5 +13,5 @@ The current revision of the Alpha board is rev03. rev01 was the board known as the 'dev-bridge'. rev02 was functionally the same as the rev03, but in another form factor. - - + + diff --git a/pelican/content/AlphaBoardStrategy.md b/pelican/content/AlphaBoardStrategy.md index 6fc5fa5..22a78fd 100644 --- a/pelican/content/AlphaBoardStrategy.md +++ b/pelican/content/AlphaBoardStrategy.md @@ -29,13 +29,11 @@ Develop a first, custom HSM board that can be used to support a first set of app ## Way forward -We currently use the Novena as a dev-board. It has a [Freescale i.MX6 CPU (ARM Cortex A9)](http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&tab=Documentation_Tab&pspll=1&SelectedAsset=Documentation&ProdMetaId=PID/DC/i.MX6Q&fromPSP=true&assetLockedForNavigation=true&componentId=2&leftNavCode=1&pageSize=25&Documentation=Documentation/00610Ksd1nd%60%60Data%20Sheets&fpsp=1&linkline=Data%20Sheets), and a Xilinx Spartan-6 LX45 CSG324-packaged FPGA. - +We currently use the Novena as a dev-board. It has a [Freescale i.MX6 CPU (ARM Cortex A9)](http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&tab=Documentation_Tab&pspll=1&SelectedAsset=Documentation&ProdMetaId=PID/DC/i.MX6Q&fromPSP=true&assetLockedForNavigation=true&componentId=2&leftNavCode=1&pageSize=25&Documentation=Documentation/00610Ksd1nd%60%60Data%20Sheets&fpsp=1&linkline=Data%20Sheets), and a Xilinx Spartan-6 LX45 CSG324-packaged FPGA.<br/> We want to over-size rather than under-size the FPGA on the Alpha board. The biggest FPGA from Xilinx/Altera that does not require tools with a commercial license that we've found is the Xilinx Artix-7 XC7A200T FBG484. -We've only considered ARM CPUs. Either about the size of Cortex M3 / M4 (or future M7) or Cortex A8 / A9. - +We've only considered ARM CPUs. Either about the size of Cortex M3 / M4 (or future M7) or Cortex A8 / A9.<br/> A design with an A8/A9 turned out to be unattractive from a complexity and price point of view, so we're going to use one of the biggest M4 we could find. STM32F429. @@ -52,15 +50,12 @@ We are currently using a Freescale proprietary interface called EIM between the ## Conclusion -Use a high-end Cortex-M4 ARM. - +Use a high-end Cortex-M4 ARM.<br/> There is a huge difference in complexity between M4 and A9, mainly because of the DDR3 memory used with A9. An M4 design will both be easier to design, cheaper to both design and build and will be fast enough for all our early use cases anyways. -Do not use the exact same FPGA, as it is too small to fit everything we need. - - +Do not use the exact same FPGA, as it is too small to fit everything we need.<br/> -Develop full schematics in-house. +Develop full schematics in-house.<br/> It turned out to be hard, costly or both, to outsource this part. We will probably spend less time developing the schematics ourselves than we would spend explaining what to develop to a third party. diff --git a/pelican/content/AlphaSealedBags.md b/pelican/content/AlphaSealedBags.md index c9c8a7a..bd19e07 100644 --- a/pelican/content/AlphaSealedBags.md +++ b/pelican/content/AlphaSealedBags.md @@ -20,7 +20,7 @@ At this time, we do not keep records of which exact unit was sent to whom. This is a picture of the currently used bags: - + diff --git a/pelican/content/CoretestHashesC5G.md b/pelican/content/CoretestHashesC5G.md index 117fd6c..d7b712d 100644 --- a/pelican/content/CoretestHashesC5G.md +++ b/pelican/content/CoretestHashesC5G.md @@ -61,7 +61,7 @@ interface connected to a FPGA device. The subsystem consists of: well as connecting the rxd and txd ports on the uart to external pins as well as clk and reset. This core repo also contains the Python command line program hash_tester we will be using to talk to coretester and perform tests of the sha1 and sha256 cores. - + *The coretest_hashes subsystem with sha1 and sha256 cores. The system is connected to a host computer via a serial interface.* diff --git a/pelican/content/CoretestHashesNovena.md b/pelican/content/CoretestHashesNovena.md index 54024cf..9e846a9 100644 --- a/pelican/content/CoretestHashesNovena.md +++ b/pelican/content/CoretestHashesNovena.md @@ -166,35 +166,35 @@ On Linux, run e.g. `/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/ise` a. Create the project: Select `File` > `New Project` - - Name: novena - - Location: .../toolruns (automatically appends "novena") - - Family: Spartan6 - - Device: XC6SLX45 - - Package: CSG324 - - Speed: -3 +- Name: novena +- Location: .../toolruns (automatically appends "novena") +- Family: Spartan6 +- Device: XC6SLX45 +- Package: CSG324 +- Speed: -3 b. Add files to the project: - - coretest/src/rtl/coretest.v - - coretest_test_core/src/rtl/coretest_test_core.v - - i2c/src/rtl/i2c.v - - i2c/src/rtl/i2c_core.v - - novena/src/rtl/coretest_hashes.v - - novena/src/rtl/novena_fpga.v - - novena/synth/coretest-novena.ucf - - sha1/src/rtl/sha1.v - - sha1/src/rtl/sha1_core.v - - sha1/src/rtl/sha1_w_mem.v - - sha256/src/rtl/sha256.v - - sha256/src/rtl/sha256_core.v - - sha256/src/rtl/sha256_k_constants.v - - sha256/src/rtl/sha256_w_mem.v - - sha512/src/rtl/sha512.v - - sha512/src/rtl/sha512_core.v - - sha512/src/rtl/sha512_h_constants.v - - sha512/src/rtl/sha512_k_constants.v - - sha512/src/rtl/sha512_w_mem.v +- coretest/src/rtl/coretest.v +- coretest_test_core/src/rtl/coretest_test_core.v +- i2c/src/rtl/i2c.v +- i2c/src/rtl/i2c_core.v +- novena/src/rtl/coretest_hashes.v +- novena/src/rtl/novena_fpga.v +- novena/synth/coretest-novena.ucf +- sha1/src/rtl/sha1.v +- sha1/src/rtl/sha1_core.v +- sha1/src/rtl/sha1_w_mem.v +- sha256/src/rtl/sha256.v +- sha256/src/rtl/sha256_core.v +- sha256/src/rtl/sha256_k_constants.v +- sha256/src/rtl/sha256_w_mem.v +- sha512/src/rtl/sha512.v +- sha512/src/rtl/sha512_core.v +- sha512/src/rtl/sha512_h_constants.v +- sha512/src/rtl/sha512_k_constants.v +- sha512/src/rtl/sha512_w_mem.v c. Set some non-default options: @@ -203,9 +203,9 @@ c. Set some non-default options: what they mean, but they don't make things blow up.* - - In the `Process` window, right-click on `Generate Programming File`, select `Process Properties...`. - - In `Configuration Options`, find `-g UnusedPin`, and change it from `Pull Down` to `Float`. - - In `Startup Options`, find `-g DriveDone`, and check the box. +- In the `Process` window, right-click on `Generate Programming File`, select `Process Properties...`. + - In `Configuration Options`, find `-g UnusedPin`, and change it from `Pull Down` to `Float`. + - In `Startup Options`, find `-g DriveDone`, and check the box. d. Build the project @@ -217,8 +217,8 @@ The expected build time should be something like 5 and 10 minutes, depending on Some measured build times for the design: - - 5,30 minutes on [MacbookPro]({filename}MacbookPro.md) 2013 with tools in 64-bit SUSE Linux in VM - - 9,20 minutes on AMD A10-6800K with tools in Windows 7 in Virtualbox VM with one CPU core and 4 GByte RAM. +- 5,30 minutes on [MacbookPro]({filename}MacbookPro.md) 2013 with tools in 64-bit SUSE Linux in VM +- 9,20 minutes on AMD A10-6800K with tools in Windows 7 in Virtualbox VM with one CPU core and 4 GByte RAM. diff --git a/pelican/content/DNSSEC%2FRequirements.md b/pelican/content/DNSSEC%2FRequirements.md deleted file mode 100644 index cef61c4..0000000 --- a/pelican/content/DNSSEC%2FRequirements.md +++ /dev/null @@ -1,103 +0,0 @@ -Title: DNSSEC/Requirements -Author: trac -Date: 2016-12-15 22:44 - -# DNSSEC Requirements - -## Questions - - -- Should we even support SHA-1? -- GOST? - - -## Must implement - -Target DNSSEC Algorithms: - - -- RSA/SHA-256 (RFC 5702) -- RSA/SHA-512 (RFC 5702) - - -Algorithms: - - -- Hash: SHA-256 -- Hash: SHA-512 -- Sign: RSA - - -Required PKCS11 Mechs: - - -- CKM_RSA_PKCS_KEY_PAIR_GEN -- CKM_SHA256_RSA_PKCS -- CKM_SHA512_RSA_PKCS -- CKM_RSA_PKCS (possible cross-check hash with CKM_SHA256 and CKM_SHA512 before signing) -- CKM_SHA256 -- CKM_SHA512 - - -## Should implement - -Target DNSSEC Algorithms: - - -- ECDSA/P-256/SHA-256 (RFC 6605) -- ECDSA/P-384/SHA-384 (RFC 6605) - - -Algorithms: - - -- Hash: SHA-256 -- Hash: SHA-384 -- Sign: P-256 -- Sign: P-384 - - -Required PKCS11 Mechs: - - -- CKM_EC_KEY_PAIR_GEN -- CKM_ECDSA_SHA256 -- CKM_ECDSA_SHA384 -- CKM_ECDSA (possible cross-check hash with CKM_SHA256 and CKM_SHA512 before signing) -- CKM_SHA256 -- CKM_SHA384 - - -## May implement - -Target DNSSEC Algorithms: - - -- RSA/SHA-1 (RFC 3110) -- GOST (RFC 5933) - - -Algorithms: - - -- Hash: SHA-1 -- Sign: RSA - - - -- Hash: GOST R 34.11-94 (RFC5831) -- Sign: GOST R 34.10-2001 (RFC5832) - - -Required PKCS11 Mechs: - - -- CKM_RSA_PKCS_KEY_PAIR_GEN -- CKM_RSA_PKCS (possible cross-check hash with CKM_SHA_1) -- CKM_SHA1_RSA_PKCS -- CKM_SHA_1 - - - -- CKM_GOSTR3410_KEY_PAIR_GEN -- CKM_GOSTR3410_WITH_GOSTR3411 diff --git a/pelican/content/DevBridgeBoard.md b/pelican/content/DevBridgeBoard.md index 38c8641..8983da8 100644 --- a/pelican/content/DevBridgeBoard.md +++ b/pelican/content/DevBridgeBoard.md @@ -16,13 +16,13 @@ Schematics and layouts are at [user/ft/stm32-dev-bridge/hardware/rev01](https:// High resolution pictures of rev01 of the dev-bridge board are attached at the bottom of this page, but the following should be more than sufficient to read the silkscreens. - + - + Here is the board mounted on the Novena, attached to the programmer: - + Note that it's rather bigger than the Netgear enclosure I use to transport the Novena. (Not only does it protect the board, but I have this superstition that TSA is more comfortable with a home gateway than a bare motherboard.) diff --git a/pelican/content/DocMeet.md b/pelican/content/DocMeet.md index 9df8e95..d76150f 100644 --- a/pelican/content/DocMeet.md +++ b/pelican/content/DocMeet.md @@ -12,5 +12,5 @@ Date: 2016-12-15 22:39 ## Documents -* [140109.cryptech.pdf Presentation - Overview of Project with Funding Requests]({attach}DocMeet/140109.cryptech.pdf) +* [140109.cryptech.pdf Presentation - Overview of Project with Funding Requests]({attach}/DocMeet/140109.cryptech.pdf) * [[attachment:141002.cryptech-iij.pdf|141002.cryptech-iij.pdf [CrypTech]({filename}CrypTech.md) Presentation at Open IIJ Seminar]] diff --git a/pelican/content/Documents.md b/pelican/content/Documents.md index 94ded39..27e4039 100644 --- a/pelican/content/Documents.md +++ b/pelican/content/Documents.md @@ -13,8 +13,7 @@ Remember that links from this page to files in git repositories should use the " ``` -[Randomness Testing Tools]({filename}RandomnessTesting.md) - +[Randomness Testing Tools]({filename}RandomnessTesting.md)<br/> [Alpha board strategy]({filename}AlphaBoardStrategy.md) diff --git a/pelican/content/GettingStartedNovena.md b/pelican/content/GettingStartedNovena.md index b0a9270..135a62e 100644 --- a/pelican/content/GettingStartedNovena.md +++ b/pelican/content/GettingStartedNovena.md @@ -30,7 +30,7 @@ $ sudo apt-get upgrade ## The Avalanche Noise Board - + The avalanche noise board is a Novena daughter board that contains a zener-diode noise circuit that can be read directly by the FPGA. diff --git a/pelican/content/Hardware.md b/pelican/content/Hardware.md index d27fdb0..c685503 100644 --- a/pelican/content/Hardware.md +++ b/pelican/content/Hardware.md @@ -16,17 +16,17 @@ Various generic FPGA development boards. An Alpha version of a CrypTech HSM, currently in early design - + There is no real tamper wrapping and no tamper sensors. The tamper switch is used to simulate tamper detection to test the system's tamper reaction(s). For the ARM, we think we want - * No or minimal magic blobs because it's inside the security boundary - * Support for booting, flash file system, and USB - * Do not need memory protection or allocation, threads, video or sound or ... - * Some speed, but the crypto is done in the FPGA - * All components must be free of any GPL-like virus or restrictions +* No or minimal magic blobs because it's inside the security boundary +* Support for booting, flash file system, and USB +* Do not need memory protection or allocation, threads, video or sound or ... +* Some speed, but the crypto is done in the FPGA +* All components must be free of any GPL-like virus or restrictions [The BOM and board requirements for the alpha board]({filename}AlphaBoardComponents.md). diff --git a/pelican/content/InterconnectStandards.md b/pelican/content/InterconnectStandards.md index 4ce1c83..3896a83 100644 --- a/pelican/content/InterconnectStandards.md +++ b/pelican/content/InterconnectStandards.md @@ -23,16 +23,16 @@ provide technical diversity that might be required by the system. Typical differences are: - - Performance. The capacity as well as latency. +- Performance. The capacity as well as latency. - - Intelligence. Simple master-slave read/write access or DMA-transfers, +- Intelligence. Simple master-slave read/write access or DMA-transfers, coherence support etc. - - point to point or point to multipoint. Basically bus based or switch +- point to point or point to multipoint. Basically bus based or switch fabric. @@ -40,13 +40,13 @@ system. Typical differences are: There are also non-technical differences: - - Licensing and pricing. Does using a standard add monetary cost and +- Licensing and pricing. Does using a standard add monetary cost and does using the standard infer restrictions in sharing, disclosure of source code? - - Market share. The market share is primarily interesting as basis for +- Market share. The market share is primarily interesting as basis for the availability of other cores that could be integrated. @@ -63,24 +63,24 @@ cores and subsystem GRLIB. AMBA currently contains four main interconnect types: - - APB. A simple register read/write bus used to connect simpler +- APB. A simple register read/write bus used to connect simpler devices such as timers, IRQ handlers, slow serial I/O such as UARTS and GPIO interfaces. The peripherals are connected to a common bus with a single master. - - AHB. A more advanced bus based interconnect. Supports more complex +- AHB. A more advanced bus based interconnect. Supports more complex data transfers of up to 1 kByte data. Supports multiple masters. - - AXI. A switch fabric based interconnect that supports multiple +- AXI. A switch fabric based interconnect that supports multiple parallel transfers, multiple masters etc. - - ACE. A low latency interconnect that supports cache coherency to +- ACE. A low latency interconnect that supports cache coherency to allow the design of multicore, multiprocessor systems on-chip. @@ -97,27 +97,27 @@ different AMBA interconnect types. Pros: - - Technically advanced and covers a wide range of system +- Technically advanced and covers a wide range of system requirements. - - A huge user base. +- A huge user base. - - A huge selection of third party support in terms of tools as well as +- A huge selection of third party support in terms of tools as well as cores. Most of these cores and tools are commercial and proprietary, closed source. Cons: - - Licensing. Would Cryptech need to get a license? +- Licensing. Would Cryptech need to get a license? - - Availability of open cores +- Availability of open cores @@ -139,20 +139,20 @@ as interface standard. = Pros: - - Good technical features. +- Good technical features. - - Easy integration in Nios-II based systems. +- Easy integration in Nios-II based systems. Cons: - - Limited to Altera based FPGA designs. +- Limited to Altera based FPGA designs. - - Low support from open and proprietary third party suppliers of tools +- Low support from open and proprietary third party suppliers of tools and cores. @@ -173,13 +173,13 @@ number of patents related to CoreConnect (see the license agreement). Pros: - - Good support on for systems implemented on Xilinx FPGAs. +- Good support on for systems implemented on Xilinx FPGAs. Cons: - - Low support by open cores and tools. - - License agreement. +- Low support by open cores and tools. +- License agreement. @@ -203,12 +203,12 @@ open. Pros: - - Good technical features. +- Good technical features. Cons: - - Not very common in use by open cores. +- Not very common in use by open cores. @@ -239,14 +239,14 @@ specification document itself is close to Creative Commons CC-BY. Pros: - - Fairly good technical support. - - Good support from open tools and cores. - - Public domain license. +- Fairly good technical support. +- Good support from open tools and cores. +- Public domain license. Cons: - - Not as advanced. No good coherency support for example. +- Not as advanced. No good coherency support for example. diff --git a/pelican/content/Joachim%20Str%C3%B6mbergson.md b/pelican/content/Joachim Strömbergson.md index c5e5f14..84ef71a 100644 --- a/pelican/content/Joachim%20Str%C3%B6mbergson.md +++ b/pelican/content/Joachim Strömbergson.md @@ -79,16 +79,16 @@ Project goal - - Self contained, external - - USB, - - Ethernet +- Self contained, external + - USB, + - Ethernet - - Integrated - - PCIe - - Mem module - - SD card +- Integrated + - PCIe + - Mem module + - SD card @@ -116,10 +116,10 @@ Project goal - - Time plan - - Start when - - Proto when - - v 1.0 when +- Time plan + - Start when + - Proto when + - v 1.0 when @@ -213,12 +213,12 @@ Technology - - On-line self check - - RNG - - Pathological problems - - Stuck at fixed values - - variance - - bias +- On-line self check + - RNG + - Pathological problems + - Stuck at fixed values + - variance + - bias @@ -336,5 +336,5 @@ Documentation - - Design - - Test and validation +- Design +- Test and validation diff --git a/pelican/content/MailingLists.md b/pelican/content/MailingLists.md index 6694644..3207f9e 100644 --- a/pelican/content/MailingLists.md +++ b/pelican/content/MailingLists.md @@ -8,49 +8,27 @@ Date: 2016-12-15 22:39 The following lists are open to all: -* Cryptech Project Announcements - - - announce@cryptech.is - - [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/announce) - +* Cryptech Project Announcements<br/> + announce@cryptech.is<br/> + [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/announce)<br/> [Announce List Archive](https://lists.cryptech.is/archives/announce/) - -* General technology and engineering list - - - tech@cryptech.is - - [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/tech) - +* General technology and engineering list<br/> + tech@cryptech.is<br/> + [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/tech)<br/> [Tech List Archive](https://lists.cryptech.is/archives/tech/) - -* Repository commit watch list (posting restricted) - - - commit@cryptech.is - - [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/commits) - +* Repository commit watch list (posting restricted)<br/> + commit@cryptech.is<br/> + [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/commits)<br/> [Commit List Archive](https://lists.cryptech.is/archives/commits) -The following lists require approval for subscription: - -* Cryptech Project Core Team - - - core@cryptech.is - [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/core) +The following lists require approval for subscription: +* Cryptech Project Core Team<br/> + core@cryptech.is<br/> + [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/core)<br/> [Core List Archive](https://lists.cryptech.is/archives/core/) - -* Finance, funding, administration - - - org@cryptec.is - - [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/org) - +* Finance, funding, administration<br/> + org@cryptec.is<br/> + [Subscribe/Unsubscribe](https://lists.cryptech.is/listinfo/org)<br/> [Org List Archive](https://lists.cryptech.is/archives/org/) diff --git a/pelican/content/NoisyDiode.md b/pelican/content/NoisyDiode.md index 10d052a..d6567fd 100644 --- a/pelican/content/NoisyDiode.md +++ b/pelican/content/NoisyDiode.md @@ -11,21 +11,21 @@ Avalanche breakdown is a physical process that occurs when current is forced bac The unamplified noise looks like this: - + After amplification, details are lost but the signal is now 3.3V (blue is noise before amplification, yellow is amplified) - + Many implementations on the Internet feed a similar signal into an ADC (Analog Digital converter) and use the resulting data value at the time of the sampling as entropy. The Cryptech project believes a more robust way of extracting entropy is to instead feed the noise to a Schmitt trigger and then measure the time between rising edges. This would be more robust since any analog reading of the noise (such as with an ADC) will be sensitive to changes in temperature, supplied voltage and component aging. After beeing fed through a Schmitt trigger, the noise looks like this (yellow signal, blue is just a 4 MHz clock): - + The Cryptech project has to date made a couple of different hardware entropy source boards, but they all share the same design for the avalanche noise source. The core parts of the circuit are shown below. Git repository with full schematics and source code is linked at the bottom of this page. - + Links: diff --git a/pelican/content/OpenCryptoChip.md b/pelican/content/OpenCryptoChip.md index b08e9ab..1346494 100644 --- a/pelican/content/OpenCryptoChip.md +++ b/pelican/content/OpenCryptoChip.md @@ -7,14 +7,11 @@ Date: 2016-12-15 22:44 # An Open Crypto Chip ## The Layer Cake Architecture Picture - - - - - - - +<br/> + +<br/> +<br/> ## Use Cases * RPKI/DNSSEC Signing @@ -30,7 +27,7 @@ Date: 2016-12-15 22:44 * Password management - + ## Basic Functions of Crypto Chip @@ -70,10 +67,8 @@ We need to support key wrapping. Some pointers: # Rough Cut at v0.01 Proof of Concept Feature Set As a proof of concept, to validate as much as possible the assurance of the tools and methods, and as a demonstration of the project tools, team, and architecture, we have a [proposed version 0.01 product]({filename}RoughV1.md) as a proof of concept and a demonstration of the project tools, team, and architecture - - - - +<br/> +<br/> # Ongoing Decisions and Research * Security Target Description @@ -85,10 +80,8 @@ As a proof of concept, to validate as much as possible the assurance of the tool * Prototyping Platform(s) * Documentation, Decision History, & Transparency - - - - +<br/> +<br/> # Ongoing Development diff --git a/pelican/content/RandomnessTesting.md b/pelican/content/RandomnessTesting.md index 4272bd9..67d528e 100644 --- a/pelican/content/RandomnessTesting.md +++ b/pelican/content/RandomnessTesting.md @@ -41,11 +41,11 @@ The way `dieharder` works, it simply returns a clear assessment of the test resu ### Caveats There are a number of things to keep in mind when using `dieharder`, especially so when running it on a reduced amount of test data. - * If `dieharder` reaches the end of the input file, it rewinds and uses the same test data again. This has rather drastic effects on several tests which assume that some sort of repetition in the input is a sign for a seriously flawed generator. - * The `-Y 1` option works by adding 100 to the value of `psamples` until a conclusive result is found. This works reasonably well with tests that start with a value of 100 to `psamples`, but there are tests starting with 1000, and others starting with 1. - * The `-m <n>` option also just affects the initial value of `psamples`. - * Some of the tests themselves are marked as "suspect" or "do not use" if you run `dieharder -l`. Still, `-a` runs them, for whatever reason. - * Expect about one test in a `-a` run to return a "weak" result that needs to be resolved. According to the man page, about 1 in 1000 tests (not `-a` runs!) may fail despite the fact that the input is good. In that case I suggest doubling the input size, either by using `-m <n>` (which only works in conjunction with `-a`) or by adjusting `psamples` and/or `tsamples` manually. +* If `dieharder` reaches the end of the input file, it rewinds and uses the same test data again. This has rather drastic effects on several tests which assume that some sort of repetition in the input is a sign for a seriously flawed generator. +* The `-Y 1` option works by adding 100 to the value of `psamples` until a conclusive result is found. This works reasonably well with tests that start with a value of 100 to `psamples`, but there are tests starting with 1000, and others starting with 1. +* The `-m <n>` option also just affects the initial value of `psamples`. +* Some of the tests themselves are marked as "suspect" or "do not use" if you run `dieharder -l`. Still, `-a` runs them, for whatever reason. +* Expect about one test in a `-a` run to return a "weak" result that needs to be resolved. According to the man page, about 1 in 1000 tests (not `-a` runs!) may fail despite the fact that the input is good. In that case I suggest doubling the input size, either by using `-m <n>` (which only works in conjunction with `-a`) or by adjusting `psamples` and/or `tsamples` manually. ### Installation diff --git a/pelican/content/RelatedWork.md b/pelican/content/RelatedWork.md index bd10c31..4526667 100644 --- a/pelican/content/RelatedWork.md +++ b/pelican/content/RelatedWork.md @@ -5,10 +5,8 @@ Date: 2016-12-15 22:44 # Related Work ## Richard Lamb / ICANN -[Presentation at ICANN](http://ccnso.icann.org/file/32383/download/37379) - -[Presentation at ICANN](http://ccnso.icann.org/file/40211/download/52359) - +[Presentation at ICANN](http://ccnso.icann.org/file/32383/download/37379)<br/> +[Presentation at ICANN](http://ccnso.icann.org/file/40211/download/52359)<br/> "I wrote pkcs11 libraries and also have modified BIND that offloads full RRSIG calculation (including time) to board. Clearly can use anything other than TPM to do RSA calculations." @@ -21,8 +19,7 @@ other than TPM to do RSA calculations." ## Project Turris - CZNIC -[Project Thuris Web Pages](http://www.turris.cz/en/) - +[Project Thuris Web Pages](http://www.turris.cz/en/)<br/> Project Turris is a service helping to protect its user's home network with the help of a special router. It is a not-for-profit research project of CZ.NIC, z. s. p. o., the registry of the Czech national top diff --git a/pelican/content/RoughV1.md b/pelican/content/RoughV1.md index c6bb597..1700e73 100644 --- a/pelican/content/RoughV1.md +++ b/pelican/content/RoughV1.md @@ -24,17 +24,13 @@ source out of the can. for v.2 (or whatever) we would move it down to the FPGA Verilog. ## FPGA Overview - - - - - + +<br/> +<br/> ## Sketch of TRNG Chain - - - - - + +<br/> +<br/> ## Off-FPGA diff --git a/pelican/content/StateOfPlay.md b/pelican/content/StateOfPlay.md index 31075e0..5c845cb 100644 --- a/pelican/content/StateOfPlay.md +++ b/pelican/content/StateOfPlay.md @@ -84,22 +84,22 @@ See [Spartan-6 Libraries Guide for HDL Designs](http://www.xilinx.com/support/do ### Module relationships in core/novena build - + ### Module relationships in core/novena_i2c_simple build - + ### Module relationships in core/novena_eim build - + ### Module relationships in cores/trng build By special request, here's a graph for the TRNG too, even though we don't yet have a way to speak to it from the Novena: - + ## C Code diff --git a/pelican/content/SunetInitialDevelopment.md b/pelican/content/SunetInitialDevelopment.md index 6fea985..4b64d86 100644 --- a/pelican/content/SunetInitialDevelopment.md +++ b/pelican/content/SunetInitialDevelopment.md @@ -9,133 +9,133 @@ from Secworks AB. ## Step one (Deadline 2014-02-28) - - Acquire a FPGA development platform. +- Acquire a FPGA development platform. DONE. We have a Terasic DE0 board and a Terasic Cyclone V GX starter kit board. - - Create a working development and verification flow from RTL design +- Create a working development and verification flow from RTL design downto FPGA. - - Verify the functionality of the SHA-256 core in a physical FPGA. +- Verify the functionality of the SHA-256 core in a physical FPGA. ### Actions for step one - - Select FPGA development board to acquire - - Large enough to test sub systems and possibly a complete HSM. - - Good external interfaces for communication with host systems. - - Good external interfaces to entropy sources, memories, +- Select FPGA development board to acquire + - Large enough to test sub systems and possibly a complete HSM. + - Good external interfaces for communication with host systems. + - Good external interfaces to entropy sources, memories, GPIO. Arduino Shields would be good. - - Create a survey on interconnect standards usable for Cryptech - - Availability and market share/usage in third party cores. - - License - - Technical details - Bus, fabric, performance etc. +- Create a survey on interconnect standards usable for Cryptech + - Availability and market share/usage in third party cores. + - License + - Technical details - Bus, fabric, performance etc. - - Create base coretest functionality to allow testing of cores in the +- Create base coretest functionality to allow testing of cores in the FPGA on the development board. Read and write access to registers over a known communication channel. - - Verify the development flow from Verilog RTL downto FPGA. +- Verify the development flow from Verilog RTL downto FPGA. - - Verifiera SHA-256 core using coretest. +- Verifiera SHA-256 core using coretest. - - Start FPGA tool survey - - What is available as open tools and what is the status. - - What is available as open tools from the vendors. - - Talk to people in the industry to get their views on an open toolchain. +- Start FPGA tool survey + - What is available as open tools and what is the status. + - What is available as open tools from the vendors. + - Talk to people in the industry to get their views on an open toolchain. ## Step two (Deadline 2014-03-31) - - Produce first draft of design proposal to the Cryptech True Random Number Generator (TRNG) - - Security target, security model and assumptions - - Structure, architecture - - API - - Functionality - - Online test system - - Verification model - - First two entropy sources +- Produce first draft of design proposal to the Cryptech True Random Number Generator (TRNG) + - Security target, security model and assumptions + - Structure, architecture + - API + - Functionality + - Online test system + - Verification model + - First two entropy sources - - Complete SHA-1 core. Including functional verification in FPGA. +- Complete SHA-1 core. Including functional verification in FPGA. - - First draft of SHA-256 and SHA-1 core documentation. +- First draft of SHA-256 and SHA-1 core documentation. ### Actions for step two - - Create template for documentation +- Create template for documentation - - Collect info on known TRNGs and TRNG strategies +- Collect info on known TRNGs and TRNG strategies - - Collect info on online tests being used. +- Collect info on online tests being used. - - Create proposal for architecture. +- Create proposal for architecture. - - Write implementation proposal. +- Write implementation proposal. - - Specify API. +- Specify API. - - Write security target and security model. +- Write security target and security model. - - Write assumptions and limitations. +- Write assumptions and limitations. - - Write verification model. +- Write verification model. - - Finalize SHA-1 core RTl. +- Finalize SHA-1 core RTl. - - Build SHA-1 core in FPGA. +- Build SHA-1 core in FPGA. - - Verify SHA-1 functionality in FPGA using coretest. +- Verify SHA-1 functionality in FPGA using coretest. - - Write documentation for SHA-256 core. +- Write documentation for SHA-256 core. - - Write documentation for SHA-1 core. +- Write documentation for SHA-1 core. diff --git a/pelican/content/UsingSTLink.md b/pelican/content/UsingSTLink.md index f5a99c3..c51104f 100644 --- a/pelican/content/UsingSTLink.md +++ b/pelican/content/UsingSTLink.md @@ -28,7 +28,7 @@ on the Alpha board (top, just left of center). This photo shows the correct orientation of the cables (both boards oriented so that the logo is right-side up): - + NOTE: The STM boards have an unfortunate tendency to short unexpectedly, so I recommend putting them in an enclosure. In this case, I've cut holes in diff --git a/pelican/content/WhoWeAre.md b/pelican/content/WhoWeAre.md index ee71e32..52c5e53 100644 --- a/pelican/content/WhoWeAre.md +++ b/pelican/content/WhoWeAre.md @@ -10,56 +10,35 @@ But this is not an IETF, ISOC, ... project. As the saying goes, we work for the ## Tech Core -Fredrik Thulin - -Jakob Schlyter - -[Joachim Strömbergson](Joachim Strömbergson) - -Leif Johansson - -Linus Nordberg - -Lucy Lynch - -Patrik Wallström - -Павел Шатов (Pavel Shatov) - -Peter Stuge - -[Randy Bush](https://psg.com/~randy) - -[Rob Austein](https://www.hactrn.net/sra/) - -Steven Bellovin - -Basil Dolmatov - +Fredrik Thulin<br/> +Jakob Schlyter<br/> +[Joachim Strömbergson](Joachim Strömbergson)<br/> +Leif Johansson<br/> +Linus Nordberg<br/> +Lucy Lynch<br/> +Patrik Wallström <br/> +Павел Шатов (Pavel Shatov)<br/> +Peter Stuge<br/> +[Randy Bush](https://psg.com/~randy)<br/> +[Rob Austein](https://www.hactrn.net/sra/)<br/> +Steven Bellovin<br/> +Basil Dolmatov<br/> ```#!comment == Technical Help == -Bart Preneel ![0]\\ - -Tero Kivinenv ![0]\\ - +Bart Preneel ![0]<br/> +Tero Kivinenv ![0]<br/> ``` ## IETF Help -Russ Housley - -Sean Turner - -Stephen Farrell - +Russ Housley<br/> +Sean Turner<br/> +Stephen Farrell<br/> ## Coordination -Leif Johansson - Administration - -Randy Bush - Technical - -Russ Housley / Lynn StAmour - Finding Funding - +Leif Johansson - Administration<br/> +Randy Bush - Technical<br/> +Russ Housley / Lynn StAmour - Finding Funding<br/> ------ |