Stormwind_mobile has quit [Ping timeout: 265 seconds]
bgamari_ has joined #glasgow
bgamari has quit [Ping timeout: 248 seconds]
Stormwind_mobile has joined #glasgow
<_whitenotifier-5>
[glasgow] Jan--Henrik commented on issue #176: Wrong vendor ID when intitially flashing - https://git.io/JvJsT
<_whitenotifier-5>
[glasgow] Jan--Henrik closed issue #176: Wrong vendor ID when intitially flashing - https://git.io/JveC2
Stormwind_mobile has quit [Ping timeout: 268 seconds]
DurandA59 has joined #glasgow
Stormwind_mobile has joined #glasgow
<DurandA59>
Hello there! I'd like to propose my help in order to use the secure element to authenticate original Glasgow hardware. I have some previous experience with the ATECC508A/608A to secure IoT protocols (key exchange + encryption). I am working on a thesis that includes counterfeiting protection mechanisms (but this is not the main topic) and will be
<DurandA59>
very happy if I can contribute to an actual open-source product. I saw that no code relative to the use of the ATECC508A has been done/published yet.
<whitequark>
DurandA59: we, um, decided to ditch the whole idea
<whitequark>
*but*
<whitequark>
if you really want to make it work, I have absolutely no objection to using Glasgow as a testbed, just in case that in the future, some vendor other than 1b2 (or perhaps even 1b2) decides to use ATECC after all
<whitequark>
the reason we decided to ditch it was twofold. first, the task was significantly more complicated than I anticipated. second, there was absolutely no interest from the vendor side in having authentication.
<Stormwind_mobile>
Also the "customers" are a pretty niche, low volume, and the product will be not that cheap, even in mass production.
<Stormwind_mobile>
It's not like with printer cartridges or medical certified disposable products.
<Stormwind_mobile>
I guess we will still have to wait for a few years before there's a cheap Chinese knockoff of Glasgow on eBay for 20 monetary units
<sorear>
there won’t be a chinese knockoff until there’s a proven market and there won’t be a proven market until the first party ships, I fear
<Stormwind_mobile>
For sure!
<daveshah>
I also don't think iCE40 availability from the usual sources for parts for knockoffs is good enough either
<apo>
somebody poke me when you can get 20 yen knockoff glasgows
<daveshah>
There aren't any cheapo iCE40 boards on Ali/taobao as far as I know, and I've heard complaints about this from people in China (compared to things like older Xilinx/Altera)
<DurandA59>
Uh, OK, that was unexpected. I can see on the schematic that you planned to use the secure element from a Cypress MCU (I never worked with them). Was the plan to run (a subset of) CryptoAuthLib on this MCU or to do something like a usb passthrough of i2c commands from the host computer?
<DurandA59>
Also, was the plan to generate on the device a P-256 private key and to provision a certificate signed from you/the vendor also on the device so that your host application requires no database except the key from your CA?
DurandA5961 has joined #glasgow
DurandA5961 has quit [Remote host closed the connection]
DurandA5916 has joined #glasgow
<whitequark>
DurandA59: the idea was to authenticate the device against a hardcoded list of vendors tracked in git
<whitequark>
we always have to support "self-signed" devices that people assemble themselves, so at most, a signature check failure would be a warning
<whitequark>
the host would talk to the secure element via I2C and ask it to sign something with a nonce... or something along those lines
<whitequark>
DurandA59: oh, sorry, I didn't answer your question
<DurandA59>
"the host would talk to the secure element via I2C" does the host refer to the Cypress MCU or the i2c over USB as e.g. provided by some FTDI chips.
<whitequark>
the idea was to do USB passthrough of I2C. I think there's currently no code that does that, but I could very easily add it if you want.
<whitequark>
the host refers to the PC.
<whitequark>
I'm using the secure element as essentially one of those "genuine product" holograms. it isn't supposed to affect functionality, just to tell you if it's real or fake.
DurandA59 has quit [Ping timeout: 260 seconds]
<DurandA5916>
Thanks for the clarification. Were did the technical difficulties came from?
<whitequark>
DurandA5916: I overestimated my understanding of cryptography
<whitequark>
... by a pretty large margin heh
<whitequark>
I'd actually love to see the system you design, because it's something I wanted to do but turned out to lack skills for. I'm just being completely clear on whether it's likely to be used in practice, which it is not
<Stormwind_mobile>
Is one of Glasgow's main mission goals being an educational platform?
<Stormwind_mobile>
Or is the goal a tool that you buy, use, and don't worry about anything else?
<whitequark>
latter
DurandA59 has joined #glasgow
<whitequark>
many choices in Glasgow's design have a very simple explanation, namely, i have severe ADHD
<whitequark>
so it's optimized for going from 0 to communicating with all sorts of random shit very very quickly
<whitequark>
the hardware counterpart here is a massive set of adapters I've collected over the years that go from various inconvenient formats (eMMC, FFC, TSOP48, whatever) to 2.54 pinheader
<whitequark>
for example, right now, my roommate asked me to do something with his second hand CB radio that has locked out features
<whitequark>
and I was using it to read and write the I2C EEPROM
<DurandA59>
There is nothing wrong with your approach, signing a nonce from a key stored in the secure element is the way to do it. And signing this key through vendor certificate that you also store on the device so only vendor public keys are exposed.
<whitequark>
but that got obnoxious fast, so now I'm thinking I can just turn it into an I2C EEPROM emulator
<whitequark>
the reason it has configurable pull resistors on every pin, for example, is that i cba to add them manually each time
<Stormwind_mobile>
Well... That thought sounds very ADHD. Also very useful for prototyping stuff that uses an external EEPROM or in general I2C or SPI device.
<Stormwind_mobile>
It sounds like a xxl swiss army knife with upgradeable/interchangeable parts
<whitequark>
exactly right
<gruetzkopf>
it is _very_ ADHDL compliant
<whitequark>
:D
<gruetzkopf>
-L
<Stormwind_mobile>
So I'm not sure if that makes it exactly a buy&use tool
<gruetzkopf>
see me finding stuff inside a cable box _during_ a TV show recording session and being able to talk to it
<whitequark>
it is very much buy&use, there's a wide range of built-in applets
<gruetzkopf>
the prewritten applets are very much run-and-use
<whitequark>
i have one glasgow that logs sensor data (CO2, temp, humidity) into influxdb
<whitequark>
there's a framework for connecting random sensors to random time series data sinks
<Stormwind_mobile>
More like a Lego set with a manual that hands you a bunch of models/ configurations you can immediately build and use
<whitequark>
well
<whitequark>
it's a general purpose tool
<whitequark>
i'm not sure how it could be any quicker to use than right now
<Stormwind_mobile>
gruetzkopf: nooo! The L is the most important and funny part! I looove ADHDL!!!!
<Stormwind_mobile>
I'll steal that
<whitequark>
[other than the hassle of installing python correctly, etc, which I'm working on]
<gruetzkopf>
i _really_ need to findout into which bag i packed mine, thankfully i can steal jn's from time to time
<Stormwind_mobile>
I have some thoughts...
<Stormwind_mobile>
There's stuff like Arduino intro tutorials that people are beginning to get sick of offering as a workshop, because they have done it ad nauseam.
DurandA5916 has quit [Ping timeout: 260 seconds]
<whitequark>
right, it's not exactly a tool for *introduction* to electronics because it does assume you know what you're doing to some extent
<Stormwind_mobile>
Not so much for FPGA stuff. This still feels like level 50+ wizards working on it, among peers, and nobody less than level 35 has even the chance to comprehend what they are doing, so the dungeon isn't even accessible
<whitequark>
it has fairly extensive built-in safety mechanisms, but there's only so much you can do in general
<whitequark>
ah i see what you mean
<whitequark>
the current FPGA-side code is... let's say not very great
<whitequark>
it's not horrible, but it's not easy to understand, which I started fixing and it turned into writing nMigen
<Stormwind_mobile>
So even introduction workshops to FPGA take a loot of stuff for granted, or rather there is way too much to learn/know/comprehend, than there's time in your average x-hour workshop.
<DurandA59>
How does the host interface with I2C? Is it only via UART "PirateBus style" or is there a /dev/i2c interface via a driver? I am still interested in implementing authentication if the entry barrier is not too high for communicating with the SE.
<DurandA59>
btw, please excuse-me for the delayed answers as I am on public transportation
<whitequark>
DurandA59: Glasgow does not use Linux-style kernel mode drivers, rather opting for vertical integration where everything is accessed via its Python interface
<whitequark>
if I implemented an interface for the SE, it would look something like `from glasgow.device import GlasgowHardwareDevice; GlasgowHardwareDevice().atecc_{read_write}(...)`
Stormwind_mobile has quit [Ping timeout: 240 seconds]
<DurandA59>
Is there some software infrastructure already available to interact with the i2c bus from the Cypress MCU using the host? I think you already partially answered the question but I don't have the full history.
<whitequark>
there is but it's only for the EEPROMs and nothing else
<whitequark>
(I take care to not expose more capabilities than I need)
<whitequark>
again if you want to interact with the ATECC just let me know and I'll implement it, it's a half hour of work at most
<DurandA59>
Do you think I can develop the authentication feature using a single CY7C68013A dev board? Will the firmware run with no external components/iCE40 connected? I never soldered any BGA.
<whitequark>
do you have a Glasgow?
<DurandA59>
No I don't
<whitequark>
hmmm
<whitequark>
yeah I think it'll work
Stormwind_mobile has joined #glasgow
<whitequark>
you might need to solder a large EEPROM on the board
<Stormwind_mobile>
I think there are enormous opportunities to teach "beginners" FPGA stuff, but also the amount of work that needs to go into documentation, and into compartmentalization of concepts, building blocks, stacking those on top of each other... That's a long way.
<Stormwind_mobile>
I guess a lot of nerds who are reasonably experienced with hardware could benefit a lot, because they maybe only need a few gaps closed to understand the whole building, but they lack the knowledge to even see where the gaps are and how much of the required knowledge they already have
<whitequark>
this is actually some of what i'm trying to achieve with nmigen
<whitequark>
nmigen does away with a bunch of inessential complexity in FPGAs
<whitequark>
for example, "what is synthesizable verilog"
<whitequark>
(what counts as)
<whitequark>
or, "how do I run the toolchain"
<whitequark>
or, "do I manually copy all the board pinout to my constraint file"
<Stormwind_mobile>
I once attended a FPGA lecture and seminar at university, master student level EE or CS students, and I was doing very well in the lectured and theory, and reasonably well in the seminar, doing exercises with a simulator in VHDL.
<sorear>
there are a couple people here who might be able to send you one if you need one
<Stormwind_mobile>
Unfortunately, we didn't have the time left to actually flash some boards and get to blinky
<Stormwind_mobile>
whitequark: that's very cool. Yet my gut feeling is that you still need to make people understand eventually what those tools abstract away for you, at least to really grok what is happening and how to use it.
<whitequark>
Stormwind_mobile: you misunderstand
<whitequark>
Verilog introduces a bunch of concepts you have to deal with solely because Verilog has them
<whitequark>
they have no actual relation to anything that exists inside the FPGA
<whitequark>
it's chaff
<whitequark>
regarding the toolchain and platforms, yeah, at some point you will want to look inside the abstraction
<Stormwind_mobile>
I guess you, and most here all know a lot of this stuff for years and take those for granted, as "common knowledge", more or less consciously. That's kind of what I mean by the " wizard level 50" analogy
<Stormwind_mobile>
Ah. See, I don't even know that :-D
<whitequark>
actually most people just memorize their way around awful FPGA tooling
<whitequark>
the way people memorize sin(x+pi) instead of imagining an unit circle
<Stormwind_mobile>
I was musing a bit with @helenleigh last week, how difficult it is to do intermediate level hardware workshops.
<Stormwind_mobile>
Like - getting a person that knows almost nothing to blinky is a huge step, and there are a lot of "customers". You equip them with a hand full of basic building blocks that they can combine and play. Going forward from there is a sometimes very steep and frustrating learning curve.
<whitequark>
have you seen icestudio?
<Stormwind_mobile>
And also many directions in which one could dig deeper, that all profit from some kind of hand holding, but aren't as generic anymore
<Stormwind_mobile>
Not yet
<Stormwind_mobile>
A few screencaps
<Stormwind_mobile>
That unit circle example is quite good. In have met more than one person at university that were still struggling with trigonometry - possibly for exact that very reason.
bvernoux has joined #glasgow
<Stormwind_mobile>
They were made to memorize formulas, because "it's easier", but they are only useful to solve exactly one problem, and not put in context
<whitequark>
I actually don't think it's easier, it's hard to memorize tons of boring shit
<whitequark>
similarly, I find it hard to constantly work around deficiencies in Verilog (or C)
<whitequark>
so instead I spend more effort improving tools inherently more suited for the job
<Stormwind_mobile>
So they don't know intuitively that e.g. sin(x+π) is the same as cos(x+π/2) and cos() might be way easier to implement than sin()
<Stormwind_mobile>
I also don't think it's easier, assuming you are expected to understand all of trigonometry. But I have seen teachers that rather teach isolated bits to memorize, because it's just one bit, instead of taking the patience to paint the whole picture
<Stormwind_mobile>
That's kind of what I mean by that lack of documentation difficulty.
<Stormwind_mobile>
I might be overstretching my use of analogies a bit
<whitequark>
I think the documentation in FPGA-land right now is pretty lacking, and unfortunately I have contributed to it as well
<whitequark>
(nmigen isn't very well documented)
parataxis has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 268 seconds]
<DurandA59>
whitequark so I will order one of these cheap CY7C68013A dev board and one CAT24C256W EEPROM. Before you do anything to expose more of i2c, I will see if I can run the firmware.
<DurandA59>
Thanks for your patience and your explanations.
<whitequark>
good luck!
<whitequark>
comment adc.c:40
<whitequark>
or you might get stuck in an interrupt loop
Stary has quit [Ping timeout: 268 seconds]
<DurandA59>
Well noted. Do you think I should change the clock too ?
<whitequark>
I think everything else should just work, or fail gracefully
Stary has joined #glasgow
<DurandA59>
The devboard also uses a 24Mhz crystal. Thanks and have a nice day depending on your timezone.
<whitequark>
we have a 24M crystal
<whitequark>
the FX2 only works with a 24M crystal, there's no choice
Stormwind_mobile has joined #glasgow
DurandA59 has quit [Quit: Ping timeout (120 seconds)]
Stormwind_mobile has quit [Ping timeout: 260 seconds]
<_whitenotifier-5>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+1/-1/±9] https://git.io/JvJl1
<_whitenotifier-5>
[GlasgowEmbedded/glasgow] whitequark 299ead2 - s/master/initiator/ s/slave/target/ in I2C-related code.
<_whitenotifier-5>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+1/-1/±9] https://git.io/JvJlS
<_whitenotifier-5>
[GlasgowEmbedded/glasgow] whitequark 5a53dc1 - s/master/initiator/ s/slave/target/ in I2C-related code.
<awygle>
oh, they left :( hopefully they'll come back
<awygle>
i wanted to talk about the ATECC, finding out whether it was working is what led me to discover this channel in the first place
<whitequark>
wait, you didn't know about the IRC channel?
<awygle>
nope
<awygle>
i've been off IRC for... long time. more than a year?
<whitequark>
oh
<awygle>
coinciding with my total disappearance from this very project in fact :p
<awygle>
by the way i've been meaning to thank y'all for not dropping my name (yet) from the PCB. very kind considering my level of contribution to the later revisions.
<whitequark>
well, you were pretty instrumental in getting the project off the ground. we still use your ADC/DAC calculations, for one.
<whitequark>
so it is only fair.
<awygle>
still appreciated
midnight has joined #glasgow
<midnight>
oooo it *does* exist
<whitequark>
what does?
<midnight>
this channel! :) I'm sad I missed it for so long now.
bvernoux has quit [Quit: Leaving]
<_whitenotifier-5>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JvJRe