Okay. Hello, everyone. Welcome to my talk on software update for Zephyr today. And thank you very much for joining. And to get started with this topic, software update is the most essential component of any software development cycle because today when we deploy a WordX version of the software into the field and then we see bug fixes in the latest stage or fixing things in the security level or changes in terms of security, then we update the software over the air from remote by managing the devices remotely as like managing the devices remotely. So how things will happen in terms of software update in Zephyr is the thing is the primary concentration of this particular talk. So let's get started. So firstly, a little bit about myself. I myself, Parthiban, working as a software engineer for Linux at Linux or myself do most of the concentration in development of embedded Linux varying from board break up or Uboot kernel development and consulting and the October developments are related things as in terms of Linux kernel for custom board bring up or for development platforms for various customers and also development of Zephyr recently in various customer platforms as well as board bring up and various consulting as well. So I myself live in Berlin working for Linux or people who with renomus or mostly distributed across different parts of the world already. So to get started, this is our today's agenda about software update in Zephyr. So as a whole part, this talk is actually split into two major parts like usually like systems in Linux like software agent in Linux like SW update or Mender does the operation of software update by downloading the image and as well as installing into the primary storage medium like NAND flash or EMMC or ST accordingly. So the whole operation of downloading and installing the image is completely carried out by the software update agent in terms of Linux but in terms of when it comes to Zephyr or the microcontroller platform here they're speaking about this operation is actually split between two different layers. I would say so that's how the talk is actually split. So the download part is actually handled by the application software which is actually run on top of Zephyr which is like there are available solutions like update hub or some available solutions like MCMGR and so on. And the installation part or the main part of installation is actually carried out by the MCU boot. That's like a bootloader for the Zephyr platform. So this talk will speak about the MCU boot in detail about how it is going to install the software from the storage medium which is downloaded and then the second part of the talk will explain in detail and also I have some couple of demonstrations to show based on a development board how to download the software into the memory storage using various mechanisms or various possible solutions which is available with Zephyr today. And also we discuss some future works which are planned for the next step. So let's get started. So MCU boot is actually the secure bootloader for Zephyr and Minute, Apache Minute real-time operating system which is common. So as a bootloader which is actually this is not bound to any hardware platform or not bound to any real-time operating system. So in the sense like this can be ported on top for any particular autosys. So this is hardware independent as well as the operating system independent secure bootloader. So when I say secure bootloader it does various other things other than software update or software installation itself. So what it does is actually like verifying the image in terms of signature verification and handling the encryption part and decryption part of this. So these things also handled by MCU boot. It's like chain loading of the image after verifying the image or after checking the integrity of the image. So actually there was a talk earlier on Monday by David, Mr. David Brown about the security aspects maybe you can go and check it already. So MCU boot also supports multiple boot image support. So what is like multi image support here means say for example an SOC comes with Cortex-M Cortex-M4 and as well as Cortex-M33 together. And then two of these cores needs to run independent softwares. In such cases MCU boot supports also the multi boot, multi image boot chain loading of the images located. So there was a talk already in 2018 by David Brown again. So you can refer to this talk. So then the last and most important part for this talk is about software update. So the most heavy lifting work of the software installation after downloading the image into the primary storage is actually done by MCU boot. So that's why I call as heavy lifting of installation by its operation. It's actually carried out by MCU boot. So to start with how really the memory is organized or the partition of the memory is organized in the microcontroller. So usually we have few kilobytes or maximum few megabytes of memory as a primary storage medium in our microcontroller platforms. So this is this example is directly taken from the freedom development kit for partition layout. So here you can see the device tree in the left shows various partitions which is needed or basic partitions which is needed for the MCU boot to function. So assuming here we have a flash node which is which is alias for actually the non volatil flash controller. It comes under the flash controller again. So this is the flash controller which represents the memory of the built-in memory of the controller itself. So we have under which we need to create partitions based on the needs. For example, we need to have like three partitions minimum or four partitions minimum to have over the air or software updateable system. So here the first partition is actually the MCU boot itself. So this resides at offset zero, zero cross zero. So and then depends on the size of the MCU boot. We can define the size here as well. So this is like partitioning the raw flash into multiple things. So and then the important part is lot zero. Otherwise called as primary slot where the actual chain loading image needs to be located. So one important thing here is MCU boot always tries or always boots the image from the primary slot. So when it comes to the secondary slot, here's lot one. It is meant for the purpose of software update or used for the purpose of software update. For example, by means of some external mechanisms like software downloading mechanisms like update hub or Hockbit, the new image will be downloaded into slot one and then it would be swapped or copied into slot zero. So when I say swapped or copied, this is like two different operation. So in terms of copy, it overwrites slot zero with the image which is actually downloaded into slot one by replacing the content in slot zero. And the other way of doing is actually swapping. How to swap the image here? That's why we have an additional partition code scratch. One can imagine a simple example of swapping of variables in C for in A is equal to 10, in B is equal to 20, and then swapping the values between A and B using a temporary variable C. So just assign the value of A to C and then replace it with B. So this is how the swap works. So the overall picture is like copying the image from one partition to another but using the swap scratch partition here. So that's the purpose of scratch partition in this case. So next is how the image needs to be organized so that MCU boot can understand the image and then chain load the image from the primary partition. So the image which is flashed or loaded into slot zero will contain the image itself, that's the code section, and also it contains a header which represents the size of the image and how much length it got and what is the sign key which is used and so on and so forth. So these all information, we are not going to detail it now because we are not explaining about the security aspects of the MCU boot but instead we are speaking about the software update aspects of the MCU boot. So the most important part for software update in this case is the trailer section. So the memory region in the end of an image partition is called trailer which contains certain metadata information and this metadata is actually used by the MCU boot during booting every boot up. It reads this metadata information and decides whether we need to swap the image from slot one to slot zero or just boot slot zero or we are middle of somewhere in the swapping operation and then we are interrupted with some X and Y reasons like power failure or hardware failure and so on and so forth. This metadata is named as trailer which is used by the MCU boot to decide the state of the hardware or state of the software itself to boot from. So expanding this trailer, here we have swap status which we will see in a moment and we have the swap size which will contain the total size of the image which needs to be swapped from slot one to slot zero in this case. So by having this information or inspecting this information MCU boot decides whether it needs to resume from somewhere else or it needs to start from scratch for swapping this image and also we have swap info which explains a swap type and so on and so forth. So it contains multiple things like swap type and as well as swap number which we will see in a moment. So there is also a couple of other byte information which we can see in the next slide and there is also a magic in the end of this image slot. So jumping into the next. Okay, so in overall big picture how MCU boot operates is like once we kickstart the target it goes and check whether there is an interrupted swap which means like during the swap operation the target is power failed or rebooted again or some X or Y reasons it resetted back and it was in the middle of the previous swap. It detects it by reading the metadata and see if there is an interruption. If so then it will continue the previously left place or continue the swap operation from the previously left place. If there is no interrupted swap there is a swap requested as a fresh new image which is downloaded in slot one then it's gonna check the image whether it's a valid image by checking the integrity signature, encryption part and so on and if there is a valid image which is found in slot one it's gonna start the swap operation. Now I'm gonna share my screen to show how this swap altogether works. Again this particular video or the animation is taken from YouTube which is published by Mr. David Brown, Linaro. So I'm just gonna play this one. So here we have the left one is the image slot one sorry slot zero and then we have slot one and then we have a scratch partition. So how the swap operation works is by first erasing the scratch partition and then followed by it's gonna create a trailer this is the trailer which would be used by the primary slot now so it creates a fresh trailer and also the first step it copies a piece of image here I mean by piece of image it's a sector of image from the flash so this scratch partition itself should be having enough storage memory to store the maximum size of swapable sector so assume we have 128 kilobytes of sector which needs to be swapped for every single operation then the swap scratch partition should at least contain 128 kilobytes of memory so it copies a piece of or sector of memory from the secondary slot and then it will mark a status here in the trailer saying it completed one operation and following it will move the same piece of sector or the same amount of content from the slot zero and then it moves into the slot one and then it marks the same information here in the trailer this way it tracks where exactly this swap operation is currently being left out or currently being in function so it just continues the only thing now here is the swap itself the trailer itself is moved to the end of the slot zero and it continues until the whole image is in the slot one is swapped back to slot zero so assume if it breaks in between or power failure and the MCU boots again it detects the state of where it exactly left by reading the trailer information here and then it resumes back from where it actually left so this way it checks or works in a way that it doesn't break the device altogether so I'm just going to stop this I'm just going to... so it's the same thing which is repeated here just as in the animation which you saw right now so here you can see so the trailer is created and a piece of image is copied from the slot one to the scratch area and then it is marked and then it continues so this process will continue until the whole image from slot one is copied to slot zero so this is how the swap operation is actually being carried out so to view in detail about the swap status itself it keeps record for each and every sectors which have been copied from slot one to the scratch and then scratch until it completely swaps it's like a three state information during the swap operation from slot one to slot zero so these state information will be maintained here in the swap status region of the trailer for each and every individual sectors and then by reading this particular memory in the metadata it decides whether the swap operation is complete or it was left in the partial and then it needs to resume or it needs to boot the first image so this is how it decides or MCU boot decides how to boot the new image and that's the swap operation actually so there are different types of swap here which we can see so as I said before it's not just only the swap status which decides where exactly the swap is done or how to decide MCU boot decides whether it needs to continue the swap or it needs to start the swap or it's left in the between so this is decided by this table so where it needs to read the whole metadata of the trailer the magic image okay whether it's copied done is done and so on and so forth so it decides different types based on reading the whole metadata information so this one is meant for starting the swap as a first download but the previous one here we saw during the swap operation and stores each and every sector this one is used for interrupted swap for example power failure and then it needs to resume from where it actually left so this particular swap status is used for the resuming of the interrupted swap operation and this one is actually primarily decides whether it needs to start swapping or from slot 1 to slot 0 or it just needs to put the image in slot 0 directly so this is the state which is needs to be provided or needs to be given to the MCU boot when there is a new image is downloaded to the slot 1 by the mediums like Hockpit or so on and so forth so after downloading the image how we need to inform or how we need to instruct the MCU boot that if there is a new image is done with set of APIs which is provided in Zaffer for example here we have boot underscore request and so upgrade so this in particular is used to request the request to write this bit flags to mark it as test or permanent for example if the flag permanent is written here then it is actually gonna change or swap the image from slot 1 to slot 0 and there is no test swap we will see in a moment what is actually a test swap and what is a permanent swap by examining in detail so quickly to jump back again to screen share so here I have freedom development board with me connected to my ethernet and then we just got nothing inside and then I am gonna flash the MCU boot and as you can see in the right side of the window the MCU boot boots and as there is no image in the slot 0 I just flashed MCU boot there is no other image which is flashing internally so it is just the MCU boot so it just says unable to find the bootable image because there is no bootable image in the slot 0 to continue further on this so this explains how actually the software update is actually installed after downloading the image to slot 1 so it is like after downloading our new version of the software into slot 1 then we need to inform the MCU boot by using the API and then reset the target so MCU boot reads the metadata information of both the slots 0 and slot 1 and then it decides it needs to swap the image to slot 0 but how do we get our new image into slot 1 that explains the remaining part of the presentation now so we have like few solutions available in Zephyr about how to download our new image or the next version of the image into the slot 1 partition and we are going to see one by one so here the first one which I am going to speak about is update hub what is update hub the cloud solution and as a cloud solution we can manage the device or for software update from the cloud by uploading our new version of the image and the device can either download the new image by polling method or by manually reading or checking the server if there is a new image and then we can flash the new version of the image into slot 1 partition so this solution is actually secure and also provides a total a total solution for managing multiple devices like having a roll out mechanisms for connecting all the devices to the internet and then managing the solution or managing the OTA itself so there is also couple of versions like for community, for the developers to use with and also there is a device addition which can be used for large scale devices which is deployed on the field now I am again going to jump into my screen to see how update hub works and we are going to use this example here I am just going to flash the update hub example or update hub sample application which is as part of Zephyr to my slot 0 because we don't have any image in slot 0 so far so before that I am just going to show the update hub UI here this is like a cloud which is running in my local server for now and it creates a cloud platform where you can upload your new image so after you login here you can see like devices and then roll out mechanisms which you can upload and then manage the device and now I am just going to jump back to the console to flash this image here so the one thing which I did wrong now is like I just flashed the image which is not signed and then it detects that the image in the primary slot is not valid because I flashed a plain image instead of the signed image so how we can I am going to flash the signed image and it is going to boot the signed image and it connects to the update hub server to make the device visible as you can see it now boots the image in the primary slot and it communicates with the cloud and it says there is no update available because we didn't push any updates here in our update hub itself here you can see this new device is just populated after starting this application here in the device now we are going to just upload the new package which I already created with actually the different version or altogether a completely different application I am just going to upload this package and there is also procedures like in the in the Zephyr documentation you can find the how to create the package version of the package or how to upload or how to sign these things so how to sign this new image everything is part of the documentation already so now I am going to create a rollout mechanism or rollout for this particular device and the image which I just uploaded is version is 2.0 and I am going to create the rollout for this new device or new version of software I am going to start this upload process it is like the process is started and it says the operation is pending now I am going to run update hub run in my control of the device and it is going to pull the new image and it says the new image is downloaded and flashed successfully and then you can view the changes here as well in the cloud UI so now I am going to reset the target and now you can see the new image is actually swapped as we saw in our animation or in our slide previously and then the new images copied back to the slot 0 and this is actually just a hello world application which is actually pushed from the cloud so the new image is now flashed and we can see this image is up and running so once this is done based on the application we need to notify the update server to say our update is done or failed accordingly but haven't done anything so that means just rolling for or waiting for the status from the status from the device itself so by this we can see like any number of devices which can be managed for managing the software update itself so the remaining part here is actually exactly the same thing which we saw I just have these slides because I was not sure whether the screen share will work or will not work so it's the same thing which you can see like the new image will be downloaded and then once you have the new image downloaded you see the status change in the cloud UI so that's about the update hub and how it exactly works so this particular solution works directly by connecting your device to the internet now I connected with ethernet and connected to the internet and then it uploads and downloads the image over ethernet or any form of internet medium so maybe wifi or modem which can be also together used in this cases so the next solution which we can see now is mcu manager so this solution is actually developed by Apache for their autos like my new autos and it also have the porting to zephyr as like mcu boot this is not hardware dependent or operating system dependent so there is a port for there can be a port for any number of real time operating system so here we have port for zephyr and we are going to see how this works with the zephyr OTA or software update itself so as an architecture point of view how exactly this is layered is it can address any form of physical mediums except the management layer itself all the rest is actually modular or pluggable based on the use cases by mean I here mean that today we have bluetooth shell and udp way of communicating towards the devices and server this we can assume like a client server model it can connect between clients and server using bluetooth or shell by using the uod connection or udp and future it can be extended further into further communication mediums like wi-fi or or so on and so forth this layer is modular so the simple management protocol by itself is modular in such a way that it can be extended to any communication mediums here so this management layer here actually takes commands from the server and handles the commands or forwards the command to the respective command manager here in this case for software update we need to speak about image management and the image management takes care to respond back with your response like uploading the image or downloading the image and then verifying the image and so on so forth so this is like a commands and it is managed by the image management layer itself so this whole thing between the management and the communication is actually attributed by seabor standard and this is like a binary format and this formatted data is examined by the management layer and forwarded back to the image management layer so that way it manages the images in the devices I am going to again share my screen now I am going to use my sd microelectronics discovery board with me for this particular example so here you can see the device got nothing I didn't flash anything into this image to start with we need to flash the mcu boot itself in the primaries in the initial 0x0 memory and then we need to further need to flash the application itself in the primary slot and then we need to download the image from using the mcu-mgr use case or mcu-mgr client to the secondary slot so now I flash the mcu boot as like before and then I am just going to flash the smp server with this simple management protocol server and the device acts as a server and we will control from my Raspberry Pi as a client to speak with the device and whether to upload a new image or query the image so on and so forth again I did the same mistake sorry instead of flashing the signed image I did flash the unsigned image now I did flash the signed image into the primary slot and then it just puts into the primary slot there is something wrong with the sample or I am going to try if it does not work maybe I will just jump back to the presentation where I have the same things explained in slides unfortunately there is something wrong with my demo maybe I can jump back to the presentation to show how it actually functions so assuming the device itself is flashed with the simple management protocol server application then from the client side or client part we can query the device over bluetooth for example or if the connection medium itself is like serial UR then it can be controlled with serial UR or recently there is support for UDP as well it can be connected with UDP so here there are few image management commands as I said before so we have the image management control which handles multiple operations like listing the image or uploading the new image or verifying the new image and so on so this is like couple of commands which is explained what is the image which is listed in the or total number of images which is part of the image part of the device here we have 0 with image which is currently running and there is no image in the slot 1 that is what we are going to download or upload from here once it is uploaded you can list this new image and also you can confirm this image by calling as confirm so what is the state which is previously in mcu well by speaking about mcu boot and it says state or flags here after the new image which is downloaded into slot 1 this is marked as pending because this is like a test image to make sure that this image is swapped back to slot 0 and it boots fine and it is not breaking the device or it is not failing with some error in the software so this way it is like we are testing it for once and then confirming it as a next step from either from the software itself or from the mcu manager client itself so this can be managed from either the application or from the client directly controlling the device so here the state is mentioned as or tagged as pending which means this is a test start and then during the next boot it tests and swaps the image as like as we saw like in update hub cases it is just going to swap the image and we see this image is swapped and if you see this image is booted fine then we can confirm the image in the primary slot which means like the image which we downloaded now so by calling it as confirmed from the mcu mcu client or in the application itself or in the binary itself in zephyr application itself we can mark this as a good image so if this image is marked good then it is like from the next boot it would start the image directly if there is if this image is not confirmed then as mcu boot during booting of the image in the primary slot it examines this metadata in the trailer and decides whether needs to boot this image in slot 0 or if it is not confirmed then it reverts back saying swaps back the image from slot 1 to slot 0 again saying this image is not confirmed so this way the device is not bricked with bad software and it is a nice way of doing to have a not bricked device in the field okay so there is also other way of doing software update which is actually with can open which is recently added in zephyr which can be used for as like mcu mgr or with update hub can also be used for software update but we are not going to speak about it now but as an overall solution what is the limitation which we or what is the thing which is really missing in this aspects so we have a solution called mcu manager which takes care for local radio and couple of cases using the cbor attributes managing the images and there is also solution which is based on update hub when the device is connected to the internet but there is no unified solution which is currently available in zephyr for handling both of these cases together assuming for an example of sw update as an unified solution which handles in linux at least it handles the image download from hokbit or local server or multiple other cases like usb download and so on and so forth so this is like one unified solution which is not available in zephyr to address all the use cases at least in terms of internet of things we have assuming a case where 10 to 15 devices connected inside an industry and connected in a star topology towards the gateway which could be linux and updating such solution or such devices which is not connected to the internet but connected to the centralized gateway is a serious job or the solutions which we discuss so far doesn't address this problem so this is the current state of these zephyr implementations so how we gonna extend this solution is by having a different architecture called zupdate and so far the state of zupdate is not complete at least which is not yet pushed to the main line zephyr which we developed started developing a year ago which is still ongoing and we are addressing various aspects of the limitations and problems by having this particular architecture called zupdate to address all possible form of software updates whether it's like a star topology connecting towards a centralized gateway in an internet of things topology or it's just a single device connecting directly to the internet or it's a single device just lying in a local radio like bluetooth or lora and so forth so this is this particular architecture addresses or influenced directly from the solution svupdate in linux so by having a model a solution for handling the download infrastructure by having a download handler which is connected towards the zephyr zupdate core and the other side of the zupdate by flashing the image to the primary flash or if it is not a binary update it could be a configuration update from the server or key management change of key for the security or change of x or y information which doesn't always necessarily go to the flash primary flash but also it can go to the spinar flash or other storage mediums as well so this modular architecture which we have right here is handling multiple other forms of solutions like cockpit update hub and it can extend towards other solutions like svupdate here I say svupdate because when you have a star topology in an internet of things network where the zephyr gateway or sorry linux gateway lives in the center and connected to all the zephyr nodes or the zephyr devices in a local radio and the swupdate can download the image directly from its source and updates itself in the linux machine or updating the gateway itself and also we can control the software update of all the client devices which is connected in this network which is actually zephyr by having this zupdate so by having an additional handler in swupdate this is directly possible but also not just swupdate but also with other solutions like mender and so on so this solution or this architecture is designed in such a way that it can be modular to any form of further software update mechanisms so by the device itself can be connected to the internet or it is not connected to the internet it can be managed in such a way for both connecting to the internet cases and as well as non-connecting to the internet cases like local failures so far we started implementing the code part of the zupdate architecture and it's still under way but we started with Hockpit as an example which is again another device management or cloud management solution for the software update mechanism so something like something similar to update hub but this update Hockpit case is an example we use to bind together with zupdate and it worked well so this is how it is organized where the cloud infrastructure is running any solution for this case is Hockpit and it connects towards the internet and then we connect the device directly to the internet so this could be connecting directly to the internet in this case like the freedom development board connecting directly to the internet and pulling the image from the Hockpit server but managing the software update not by directly flashing into the spine or not by directly handling it but by having a download manager handling the downloading part and flashing with the storage manager from the zupdate core itself so we started with the solution and this is like partially complete and it's working but for now the mainline version of the zupdate is not yet complete but it just have the solution for the Hockpit itself directly so maybe before the time runs out I can just quickly try showcase or show the example of how Hockpit works so as like the update of solution we have Hockpit server where you can login to the server and see upload the image and manage the rollout mechanisms now I'm just gonna sorry let's forget to share my screen so here I have the Hockpit server logged in maybe I can login back again so here we can manage the devices for the rollout management as like update hub but from the device point of view I'm just gonna reflash the device with some example to start it from fresh so now we have the simple hello world example and then I'm just gonna flash like as before the MCU boot first into the target now we have MCU boot so I think I run into some problem and we are running out of time maybe I can just show this case directly in the presentation itself so here we manage the devices upload the image directly in the update hub as like in the Hockpit as like update hub and in the device side you can see the image will be downloaded into the secondary slot and then it would be replaced by the MCU boot during the software update but what is the difference between here is like it's managed by z-update infrastructure instead of the direct update mechanisms as like before we see in the update hub and so on so this particular architecture which we see as an example here after the update the image is changed and then we see the status of the image to successful as like update hub as well so so far we have the solution for z-update is currently underway but it's not yet complete but not yet complete in the sense it is having the base infrastructure ready but not yet covering most of the local radios like Lora and so on this needs to be extended further so this is not yet done and we are currently working on it and then we move to this separate mainline as well so this solution is flexible in such a way that such a way that it can be extended to any form of cloud solution like update hub or cockpit or any other solutions which we can upload the image directly and then also handle the local radio cases and also the Linux OTA agents like SW update or Mender or so on so that's the major part which I want to speak that's it for now if you have any questions I will jump into the keyword part and see if I can address the plot of questions before moving into this slack so Mahindran asked where does the key store stored so in case of MCU boot it is directly embedded as part of MCU boot itself but this can also reside in the key store region like a separate memory region which can be part of an external chip like TPM or it can be part of any other secure devices then the next question there is support for 3 images current update and recovery yes there is support for recovery as well but we haven't discussed this particular part in this talk specifically to just make things simple to understand the swap operation and how update works but there is yes there is support for recovery as part of MCU boot and there is next question what if the only transport available for uploading is BLE and is the transport catered for not sure if I understand correctly what if the only transport available for uploading is BLE so I don't think there will be a problem in uploading with BLE in case of MCU manager or other mediums as well I think that's the questions which I can see in the slides right now I'm not sure if I have to scroll okay so is there any z-update documentation code available online yet yes it's available specifically but as I said before it's like in terms of early development internally and we just finished the cockpit part into the mainline part and it will be soon merged in like in coming days and yes the z-update part documentation and as well as the functionality is not yet in the mainline which will be soon available maybe I can say in next month because I have already a stable solution running so thank you very much for joining and I will be ready to take questions directly from Slack from now and then we already run out of time across our limit so thank you very much again and have a nice day stay healthy thank you


Loading a roll of film into a new camera is like coming home. Back to where it all started. The beginning of my photographic journey. In the spirit of exploration. In the spirit of discovery. That's where it all started for me. And it started with a roll of 35 millimeter film. Well I'm back to the spot I was in the autumn. And here we are late winter. I wanted to see what this looked like. We've had changed. I shot it in digital last time. And I also wanted to try it in film. Today we've got a 35 millimeter film. I'm shooting this with T-Max 100. If you haven't seen my last video. This camera was donated by Old Film Guy. I also know him as Robert Gully. Robert was generous and offered me this camera to use on this channel. Very generous offer. I much appreciate it. So you could say this video is brought to you by Old Film Guy. I have a 24 exposure roll on this camera. I don't really want to waste a whole lot of film for some time I use the camera. I want to make sure I've got it kind of dialed in. If my exposures are going to be correct going down the road. So I'm bracketing just a little bit. I really think this is a cool scene. I've shot it with a 50 millimeter and 20 millimeter. The 50 millimeter was just a big rock in the background. I've got the whole scene and I'll have to figure out what should I like best. I really like these moss covered rocks. When I shot it in Dizzer before. I always intended to come back with film and see if there was something here that might look different in film. We're getting some side light. It's diffused but it's still directional which is actually pretty cool. This is about perfect light for wooded areas I think. It's still enough to give texture, shape, form to these rocks. But not so much that it's got a bunch of hot spots all over the place. This is actually, I couldn't have asked for better light. So the photo is no trend. It's not because of the light right now anyway. I haven't taken a photo for a while. It's been a slow start for me this year. I've got this feeling there's a photograph in here somewhere. I like the section of forest here. I've never been in here. I'm out further than I normally come here. I've only been here a few times. I've never gone out this far. And I like the section of woods over here. I'm going to see if I can make a photo in here somewhere. This is what we're looking at. I know it's kind of busy but there's a lot of depth in here. A lot of vertical lines. A lot of texture. I think I can make at least one frame in here. Let's see what we can find. I just photographed this scene right here. It's fairly cluttered. It's kind of busy. I started with this first tree and then just kind of go off to the back of it. These are a little bit bigger trees than I've been seeing. It's just more of a forest scene. Backlit. Hopefully I've got a little shine on the ferns. I'm thinking about blowing my last composition right here on this. I really like the texture of this bark. And these ferns in the foreground might make a little foreground interest. I probably will center that right in the middle and then have this kind of circular fern growth underneath it. It's one of those things where the viewfinder kind of works. That's what I love about doing 35mm. If it doesn't work, it doesn't work. I'm not out that much, you know? It's good to be experimental and playful. Sometimes you get your best shots that way. I've looked around here. There's so much potential here. I think if we'll miss in here, boy that would be so cool. Today it's just been so nice to be out. Perfect weather. Starting to sprinkle a little bit. That's okay. We're heading back to the car. I'm going to go ahead and see if I can set up composition on this. We've got our last frame exposed. Finished up the roll. Hopefully we've got something to show you. I don't think there's going to be any portfolio pieces here today but it was a lot of fun making shots. Again, I'd like to thank Robert for donating the camera. It's much appreciated. I hope you enjoyed this little trip out in the nature. Until next time, thanks for coming along for the ride. I know that someday film may not be a choice for me. So for now I'm going to continue in that spirit of exploration and discovery using the cameras of my youth. Going back to where it all started.


And we are from CryptoMail.org, a truth secure email for everyone. Okay, today we're going to talk about the problem statement that address the problem with web-based secure email. Then George will talk about omissions and objectives that solve the problem with web-based email. Then he will address the algorithms and protocols that use in applications. Next, he will give you a live program demonstration and show you how this program works. Then he will talk about the current platform and server platform mechanisms. At the end of the presentations, we will talk about the future directions and where we're going. At the end, you are welcome to ask any question you might have in our Q&A sessions. And here it goes, that you continue to talk to us. George said about. Okay, thanks Peter. Okay, here are the problem statements. Why is encrypted email important? It protects your privacy and it protects your assets. Let's say Peter wants to send me an email message that tells me when the next rave is and what the next secret rave location is. Or let's say he's got a piece of financial data that he wants to convey to me and wants to keep it confidential. So Peter wants to do so by keeping it confidential, so he's going to have to use encryption. The second reason why it's important is because as we all know, cryptography is free speech. And basically we believe that you should use it. You should use it in a pervasive manner or it's going to get taken away from you.  So another part of the problem is how do we get people to use encrypted email? The grandma problem. How do you get your grandma who knows nothing about keys, encryption, privacy, or anything like that to use encryption? You have to get her to use it with almost not even knowing that she's using it. Also the encryption has to be basically roaming. You should be able to walk up to any terminal, any web-based, capable client, and be able to log in and use these encryption faculties. So let's say you've got your home machine and you do things with PGP on your home machine. In theory you should be able to go to Kinko's or go to your friend's house and still send encrypted email messages with confidentiality. The software's got to just work. It just has to install itself. There's no active on the behalf of the user installation. It doesn't muck with a registry. It doesn't do any of that stuff. It shouldn't do any of that stuff. So it's got a very low footprint in terms of user implication and installation. The experience has got to be ubiquitous. When you use encrypted email, it's got to look like email, otherwise no one's going to use it. It's just got to look like standard email messaging. You've got to manage people's keys. There's no key fumbling. Grandma doesn't know about somebody's PGP key. Here, grandma, cut this, paste this, and then use this program in order to import it into your key ring. Do you think you're grandma? Well, you guys come from a different gene lineage, so maybe your grandmas are capable of this. But my grandma really can't. I can't tell her to send me that secret cookie recipe by telling her to import my public key. We want to make the implementation that we're doing basically accessible. We want open source, free source with full disclosure, and we want to use basic standards. So we're going to use standard web servers, standard databases, everything basically unencumbered. So those are the problems. What are the missions? Our mission is to promote the freedom of private communications, okay? And our technical objectives are basically just lock down the transport level and lock down end-to-end message security. Okay, algorithms and protocols. I've got some very bright luminaries here, and they're actually here, some of them. Hi, John. Let's see. There's their encryption algorithms. Okay, I'm using Message Encryption Open PGP now. Basically, it's RFC 2440.  So that's the specification that we're going to be going with. And our transport layer encryption that our agent is going to be using is Blowfish. It uses Blowfish 128, which is a public domain unencumbered symmetric cypher. Works great. Now, my protocols, which are on top of the previous two protocols are SexMap, which is Secure XML Message Access Protocol, and XMap, which is XML Message Access Protocol. XMap basically describes a way for you to send, receive, get folder listings and do directories and stuff like that from a mailbox. Not much unlike IMAP, but it just uses XML. And Secure XML basically takes that and it just makes it a little more secure. It adds a security layer on top. So all of this is pretty much open. If you're interested in the intricacies and the details, you can go to cryptomail.org documentation protocol specifications. And so you can read up on everything that I'm about to talk about in terms of the protocols. Now, our current five-minute goal is basically to accommodate the scenario I was talking to you about, where you go to Kinko's and all you have is this clunky web browser with a low baseline JVM with a Java virtual machine. That's that 1.1 compliance, okay? That's how low it is. And so basically the Java faculties at the time when they released 1.1 didn't have SSL capabilities. So because of that, we had to figure out a way to get the applet kind of like parameterized securely through SSL. But yet when the applet talks to the server, it can do so with a high level of confidentiality. And so the next process I'm going to be talking about, which is kind of painful, is the SSI. It's Secure Session Initialization. Okay, what happens?  So you basically get this form and you pass in your username. Then the server generates a 16-byte session encryption key. This key is going to be used in order to encrypt all the communications from the client to the server in the payload. Then the server generates a 16-byte session token. I mean, a session token is just a session token. It's a unique identifier that basically describes your session with the server. Then the server generates a 16-byte random blowfish key, which I'm going to call the cloak key. And this key is kind of special. Then the server gives a 16-byte session cloak token. So you've got this cloak token, which is just another kind of token, and you've got this cloak key. So in theory, at this point, the applet and the server know all these parameters, and they've been passed through SSL. So in theory, no one knows what they are except the client and the server. So you slam in your password. Then the applet cbc blowfish encrypts the session cloak token with the cloak key. So you've got this cloak token, and you've got the cloak key. So then it encrypts the cloak token with the cloak key. Then the applet encrypts the data payload with the session key. And then basically this is what it's going to look like. So you've got your session ID, which is your unique session identifier. Then you've got in the header, you've got your cloak key, and then all your data. Then it gets posted to the server. Okay, so that gets to the server. And then basically the server just looks up the session through the session ID. And now it cbc decrypts the cloak, okay, using the cloak key. Now the server then compares the cloak token with the one that was decrypted with the one that's in the database. And if they are the same, then we know that this in fact is the applet that originated the secure session initialization. And the reason we do that is it's kind of, it's just in a quick asset test. Because if we didn't do that and we just sent over the encrypted payload with the session key, the server would actually have to go through the painful process of eventuating the bounce of the message. So let's say someone gives you this huge encrypted blob, and then someone says, here, decrypt it.   So we give this little asset test in the preamble that says, okay, here's the challenge. And basically, if it gets decrypted, then you're going to pass the challenge. So it's just like, it's a little mini me. It's a little mini payload. Okay, so that's the purpose of the cloak. Now as a minor recap, we locked down normal HTTP traffic with SSL applet parameterization. The applet is posting this through normal HTTP. It doesn't use HTTPS. Okay, so now that we have the transport and we can purport, it's relatively secure. We want to authenticate and get our PGP keys from the server, because now we're going to be moving to open PGP. Okay, so when you log in, the applet sends half of the shawl one of your passphrase. So for example, if your passphrase is big boobs are good, that's your resulting hash, and the applet is going to send half the hash of that passphrase. Now the data payload that you see on the bottom there is going to be encrypted with the session, but for your perusing pleasure, it's not encrypted, just like the other picture was. So this data payload gets to the server, okay, and then if half the hash matches, you get your public key and your encrypted private key. Now remember, I'm going to say that your private key is protected with the entirety of your passphrase. So when you log in and you attempt to get your public and private keys, you're only sending half the hash of the passphrase. So basically, if for whatever reason the half the hash of the passphrase is incorrect, then you're going to get booted, and it's not going to return any of your keys. And let's say you do authenticate and it did pass you back your encrypted private key and your public key. Basically, the applet then obtains a copy of the GNU Privacy Guard. It downloads it from the server and it checks the hash of it. And then the applet just simply just hands off the keys to GNU Privacy Guard for importation. And so what we've got working right now is we've got an applet that can do Linux x86 and Windows implementations of the GNU Privacy Guard. And basically, the reason why we can do this is because of Java. When you sign your applets and the user accepts the certs, it basically allows you to gain escalated pricks. So let's go over the process of creating a crypto mail account. Basically, you go to a new account page which you saw over here. Sorry, hold on a second. There we go. And you basically pick your username and you submit a form. Then basically the server goes through the painstaking SSI process that we went over before. It creates a session, it creates a session encryption key, it creates a session token, and then it creates a cloak, I'm sorry, it creates a cloak and a cloak key. When you submit, the client is going to send the session, the encrypted cloak, that's for SSI again. And it's going to send the entirety of the public key, the encrypted private key that's encrypted with the entirety of the passphrase and then half the hash of the passphrase. So when that reaches the server, basically it decrypts it and it stores this information for you in its database and then it just sends a little response, I kiss you. And that's from back in the day when some web war was going on when Mahir was making pages. And I don't know if you guys remember that, but that was kind of when I was developing the protocol.  Okay, so let's go to the program demonstration. I'm going to first create an account, then I'm going to log in, I'll send mail, receive mail, I'll go over the key manager, I'll go over client folder manipulation, client option, I might strip. Just kidding. Okay, so what username should I do? Oops, caps lock. Def, C-O-N, DefCon. So it's going through SSI. Okay, I accept the poison. Okay, you can use existing keys if you want. Like if you have PGP keys, you can import them into the system, and you have to disclose what your passphrase is so that I can save half the hash of it. So it allows you to do that. So I'm going to do DefCon. And the email notification is kind of a Biff mechanism.  Like whenever you receive mail, it kind of like pages you. This allows you to get a page every time you receive an email. Okay, so I'll just create new keys. And of course, you know, B-I-G-B-O-O-B-S-R-G-O-D. B-I-G-B-O-O-B-S-R-G-O-D. Okay, GPG is chugging away. It's prioritized with 2048 Algamol. Okay, I'm ready to log in. So I'm going to log in now. Okay, B-I-G-B-O-O-B-S-R-G-O-D. Okay, I'm in. All right. What should I do next? Should I send an email? I'm going to send an email. I'm going to send an email to DefCon 12. Or maybe not. Let me send an email to myself first. DefCon. Hey, subject, not cryptid. Sorry. Don't read. Subject. Uh-oh, I have a mail. Okay, this is what the message looks like, unencrypted. So basically you have your GPG message. And then there it is. Oh, sorry, sorry. How's that? Okay, sorry. Oops, there you go. This is your GPG message and unencrypted. And then here it is decrypted. Okay, so why don't I try and send a message to DefCon 12? I can't believe I made an account of DefCon 12. Okay, sorry. All right, shock me next time. Oh, I didn't create that user. Okay, let's see, who did I create? Oh, okay, I'm in the system. Okay, so I'm going to log out. And let's see. I'll go to login as Joshua T. Excuse me. And we're going to play with the key manager there. Okay, I'm in. Off the screen, don't shock me. Okay, now let's go play with the key manager. The key manager is kind of fun. We could see basically this is my list of keys. Now, if I try to send a message to DefCon 12, well, I'm sorry, if I try to send a message to DefCon, that guy's key is going to be automatically put into my key ring. Okay, so let's go to the key manager here. Uh-oh, it's not in there. Anyway, it's a small bug. Anyway, what you can do is you can import your keys. Okay, and you can do it through any number of ways. Okay, you could import it through a paste. So if you had a public or private key that you wanted to paste in, you could. Oh, wait, there it is. Hey, sorry, it was just a display issue. There's DefCon. Okay. Or you can import through a file.  So that's basically the key manager. Well, I'll create a little folder. Subtrash. Okay. Hey, why don't I move this message to Subtrash? Okay. Why don't I delete this? And that's it. That's basically a crypto mail. That's a new version. It's using OpenPGP. It's shelling out. Okay. It's downloading the new Privacy Guard. It means escalated privs. It checks the hash of the GPG to make sure it's not running anything too weird. And it then employs that as the message encryption. So let me go back to the presentation. There we go. So XMAP is basically for mail and file system services. It's just XML message access protocol.  It's not IMAP. I was not really interested in using IMAP. And there were a number of reasons why. I didn't have the time to audit the code. There was a lot of unencumbered IMAP server code out there. I just didn't have the time to kind of audit it and make sure it wasn't doing anything. I really didn't have control over, immediate control over. I needed to develop this PDQ. So I just took Jim Clark's XPAC processor and put it into the crypto mail code. And so XML is a really good way to get your protocols and your apps up and running pretty damn quickly. So I kind of like that. The client platform, all messages are encrypted in the client. Basically the applets signed to allow a local file system access and shelling out and stuff like that. And it works in any Java-enabled browser where GPG can work and run. And it's got a nice ubiquitous interface. I'm sure it could use improvement. And I'd like to hear from all of you later about those improvements that I'm supposed to be making. And on the server platform, I've got MySQL 323 Plus for all the data storage. Okay, the current XMAP driver is using MySQL as a database. It doesn't use the file system. Everything's in the database nice and indexed and so you can get to the stuff quickly and scaleably. And it uses any Unix-based web server that does our Proc CGI. So if you've got Netscape or you've got Apache, what have you, it just requires our Proc CGI. And the session encryption employs the GPG Cypher library and uses send mail as the mail transfer agent. And here's a little picture of the schema that we got going on. You can all take a look at it in your spare time. Basically this is the sessions, the user base, the sequence and the data table stuff. So where is all this going? What needs to happen in order for crypto mail to be better? Or what needs to happen in general? Well, okay, one of the problems is we need to be able to send secure mail across federated domains. So how do you do that? There's certainly a number of schemes you can employ and we're currently looking and searching for those solutions. And we're considering getting on the LDAP bandwagon and starting to share and get keys using LDAP. Maybe crypto mail should then, after doing some more of the email work, maybe we should branch out into the instant messenger space so that grandma can send you instant messages. And on the architectural front, maybe we should not be using a Java applet. Although it's kind of cool, people may be used to more HTML mail approaches. So the idea would be you just have this middle tier browser object and you have HTML as your display. And so you use JavaScript to kind of bridge the gap between the HTML and the encryption and stuff like that. And maybe we should add privacy enhancements like time release messages so no one knows that you're logged on and sending and receiving mail. So that would be kind of nice. And maybe we should add alerting and rules-based processing. Whenever you get a message from X at Calm, it should biff some other site than the one that you currently have. So I mean there's all kinds of rules-based features that we're thinking of doing in order to make the experience better. Okay, so here's where the code is right now. This is an alpha version. We have not deployed this at CryptoMail.org. We need your feedback. Before we do anything, we need some salient input. So if you guys can write this down, it's at CryptoMail.org slash alpha slash index dot html. Now especially for you guys, so the username is alpha and the password is Defcon12. So in the next coming months, we're going to be migrating everyone over to this. And what I personally would like to do is I'd like to contact anyone who wants to get this up and running right now. I will help do so personally. Okay, it's really, really easy. So if you've got control of a domain and a mail server or whatever and you want to give CryptoMail a try, all you have to do is just mail me and I will definitely help you get it up. It's really easy. If you download the code and you just read the read me, you should be able to do it yourself. But in the event that you can't or you just want to talk, I can give you more of my personal information later. In fact, I'll give you my email address. It's joshwatee at CryptoMail.org. J-O-S-H-U-A-T at CryptoMail.org. I'll be more than happy to help any of you set it up if you want. Okay, so now we're on to the question and answer portion. And I'll leave the floor open to you guys. Yes, Mr. Lucky. Okay. Hushmail employees... Hushmail does not shell out. See, what they do is they have vertically independent Java PGP code. Now, I have to give them major props because that's not a small undertaking. You know, they did it... I believe some of the guys from cryptics may have worked on that. And they're continuously developing that and they do a very, very excellent job on that. And the one thing that... The one advantage I have, you know, if I may call it a silly advantage, is that the implementation of my applet is actually maybe smaller because it doesn't have to download all that PGP Java stuff. Because when the client runs, it downloads the GNU Privacy Guard only once. And if it's not in your cache, then it goes and downloads it again. I think it'll go and download it again. But also, mine may be a little bit faster because it's running natively. But I certainly have the distinct disadvantage of not being vertically independent. And that's one of the things that was hard for me to sleep at night, knowing that I was just going to cop out and just shell out. But anyway, that's what I did. And that's one of the market differences. Also, they actually have a middle-tier browser object model. They render an HTML and they communicate with the browser middle-tier through JavaScript. And that might be a direction that crypto mail may want to go in. Yes, sir. Okay, that's a very good question. In the Cyber Cafe, I believe the VMs, I don't think Sun's implementation allows that super lockdown stuff. I mean, personally, I haven't tried it. So maybe if you could get into that really lockdown state, maybe you could give it a try. But from what I know, I think if you have the Sun version of the VM and the Sun plug-in and the applet is signed, it's going to just run with it. Now, Internet Explorer and their VM has much more fine-grained control.