RECENT BLOG NEWS
Or sign up to receive weekly email notifications containing the latest news from wolfSSL.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.
The wolfSSL holiday release is available for download!
This release includes more compatibility layer expansions, updates to the version of open source projects supported, post quantum additions, and new hardware port additions to name some of what was included. As well as 2 vulnerabilities fixed in the release bundle.
A major performance upgrade was added to wolfSSL SP C implementation for ECC. In some cases increasing the performance with the C implementation by over 20%. SP (single precision) performance is turned on by using the enable option –enable-sp.
New Feature Additions
- Curve25519 support with NXP SE050 added
- Renesas RA6M4 support with SCE Protected Mode and FSP 3.5.0
- Renesas TSIP 1.14 support for RX65N/RX72N
- Post quantum resistant algorithms used with Apache port
- NIST round 3 FALCON Signature Scheme support added to TLS 1.3 connections
- FALCON added to the benchmarking application
- Testing of cURL with wolfSSL post quantum resistant build
Compatibility Layer Additions
- Updated NGINX port to NGINX version 1.21.4
- Updated Apache port to Apache version 2.4.51
- Add support for SSL_OP_NO_TLSv1_2 flag with wolfSSL_CTX_set_options function
- Support added for the functions
- Building with Android wpa_supplicant and KeyStore
- Setting initial value of CA certificate with TSIP enabled
- Cryptocell ECC build fix and fix with RSA disabled
- IoT-SAFE improvement for Key/File slot ID size, fix for C++ compile, and fixes for retrieving the public key after key generation
Math Library Fixes
- Check return values on TFM library montgomery function in case the system runs out of memory. This resolves an edge case of invalid ECC signatures being created.
- SP math library sanity check on size of values passed to sp_gcd.
- SP math library sanity check on exponentiation by 0 with mod_exp
- Update base ECC mp_sqrtmod_prime function to handle an edge case of zero
- TFM math library with Intel MULX multiply fix for carry in assembly code
Build Options and Warnings
- Bugfix: could not build with liboqs and without DH enabled
- Build with macro NO_ECC_KEY_EXPORT fixed
- Fix for building with the macro HAVE_ENCRYPT_THEN_MAC when session export is enabled
- Building with wolfSentry and HAVE_EX_DATA macro set
- Improvement for performance with SP C implementation of montgomery reduction for ECC (P256 and P384) and SP ARM64 implementation for ECC (P384)
- With SP math handle case of dividing by length of dividend
- SP math improvement for lo/hi register names to be used with older GCC compilers
- [Low] Potential for DoS attack on a wolfSSL client due to processing hello packets of the incorrect side. This affects only connections using TLS v1.2 or less that have also been compromised by a man in the middle attack. Thanks to James Henderson, Mathy Vanhoef, Chris M. Stone, Sam L. Thomas, Nicolas Bailleut, and Tom Chothia (University of Birmingham, KU Leuven, ENS Rennes for the report.
- [Low] Client side session resumption issue once the session resumption cache has been filled up. The hijacking of a session resumption has been demonstrated so far with only non verified peer connections. That is where the client is not verifying the server’s CA that it is connecting to. There is the potential though for other cases involving proxies that are verifying the server to be at risk, if using wolfSSL in a case involving proxies use wolfSSL_get1_session and then wolfSSL_SESSION_free when done where possible. If not adding in the session get/free function calls we recommend that users of wolfSSL that are resuming sessions update to the latest version (wolfSSL version 5.1.0 or later). Thanks to the UK’s National Cyber Security Centre (NCSC) for the report.
A full list of what was changed can be found in the wolfSSL ChangeLog (https://www.wolfssl.com/docs/wolfssl-changelog/).
For questions about wolfSSL or about the latest release contact us at email@example.com
At wolfSSL, we have been developing secure boot solutions with customers for many years, and more recently we have released wolfBoot, a secure bootloader designed for embedded systems.
wolfBoot provides reliable support to remote firmware updates on a wide range of devices, supporting the most common architectures (ARM Cortex-M, ARM Cortex-A, ARM Cortex-R RISC-V RV32, PowerPC, and x86_64 via UEFI).
wolfBoot supports all types of RTOS and embedded operating systems, so it can be used to boot FreeRTOS, Contiki, RIOT-OS, ChibiOS, ThreadX, VxWorks, QNX, TRON/ITRON/uITRON, Micrium’s uC/OS, FreeRTOS, SafeRTOS, Freescale MQX, Nucleus, TinyOS, TI-RTOS, uTasker, embOS, INtime, MbedOS, Linux, and many more…
Here is our list of the top ten interesting facts about secure boot.
- Trusted firmware updates have become a requirement for IoT projects
IoT devices are not immune to cyber attacks, and many real-life cases have proven that misconfigured systems may even be an easier challenge for an attacker, and sometimes even compromise the entire distributed system from a single vulnerability in one software component.
Vulnerabilities happen. No matter whether the software is completely written from scratch or depends on third party components, defects in the implementation may surface at the worst time possible for the project timeline, and critical systems cannot afford to keep vulnerable versions running. At wolfSSL we know that security software development never sleeps. As soon as new vulnerabilities are discovered, the entire team immediately switch their focus on delivering a fix, launch all the tests and release a new version of the software.
IT services may already benefit of continuous deployment mechanisms to ensure that new versions of the software components are available to run just after they have been updated and delivered. This is a good way to reduce risks related to running outdated software in production.
Why should similar mechanisms not be widely available on embedded systems? Well, the question is complicated, due to a few aspects. The diversity of microcontrollers available on the market poses quite a few challenges for embedded systems developers to provide a unified mechanism that fits all the scenarios, use cases, platform specific hardware and sometimes unique communication interfaces and protocols. Moreover, embedded software is generally installed from a monolithic
binary file, containing a 1:1 match to the physical content of the non-volatile memory onboard. Updating a single component may be tricky unless there has been some specific partitioning mechanism in place.
The effort for defining the guidelines for a secure and safe firmware update mechanism have been lead by the SUIT group within IETF, which has studied the problem and has produced a standard RFC9019. “The document […] lists the requirements and describes an architecture for a firmware update mechanisms suitable for IoT devices.”
- Updates are verified using public-key signature authentication
The key feature offered by a secure bootloader following the SUIT definition is the use of state-of-the-art cryptography to guarantee the authenticity of the current firmware and the updates that are coming from a remote source. By using public-key based authentication it is possible to verify that all the software on board before running it.
The mechanism is quite simple: the owner of the device creates a key pair. The private key is secret, it is never revealed or stored on the device itself. The private key is used by a script or a program to sign the manifest header, which is transmitted alongside with the binary image of the new software. The manifest header contains all the meta-data associated to the firmware image.
The bootloader can access a copy of the public key, as it is stored on the non-volatile memory on board, or on a specific hardware secure vault. The public key is not a secret, and even if revealed, it does not pose any risk for the secure boot process.
When the bootloader receives the update package, it uses the public key to initiate the verification. Only software that contains valid metadata, including a verifiable signature, will be allowed to run on the target.
- Operating with small bootloaders
The secure bootloader is, in many cases, the only immutable part of an embedded system. SUIT specifications assume that in general the bootloader itself will not be uploaded because this may pose a risk in reliability. For this reason, one of the requirements for the implementation of a secure bootloader is to keep the bootloader small, and dedicate other components in the system to the task of transferring the firmware images and initiating the update.
This also means that code safety is critical in bootloader context, to guarantee the required level of reliability and minimize the attack surface. SUIT in particular mandates the use of small parsers in the code, since parsers are described as a “known source of bugs”.
One step further in this direction is to completely avoid dynamic memory allocations in the bootloader code. Measuring the memory usage at compile time and allocating static buffers for all the data structures significantly reduce the chance of memory management bugs such as overlapping of sections or heap-stack collisions when inappropriate memory mappings are configured.
A secure bootloader implementation cannot ignore resources and safety related requirements, or the risk is to create bigger issues than what it is expected to fix!
- Rollback attacks
In the perspective of continuous vulnerability management, new updates are released and made available often. Unless the firmware images are transferred using a secure channel, such as TLS, there is always a risk that an old update is intercepted by an attacker, or anyone who is sniffing the traffic towards the firmware consuming device. This is particularly true in those broadcast-friendly environments, e.g. if the firmware images are distributed through a local mesh network that does not support secure socket communication.
An attacker may know about a vulnerability in a previous version, and attempt to downgrade the firmware on the target device to that specific version, by repeating the transmission of the firmware image previously recorded by wiretapping on the network.
A secure boot mechanism must retain the information about the firmware version alongside with all the other information in the manifest header. The version number, like the rest of the meta data, is enclosed in the envelope together with the firmware image during the signing process, which means that the version cannot be altered by an attacker without compromising the validity of the signature for the update package. The bootloader will not allow to install packages with a version number that is older than the one that is currently running on the system.
Rollback attacks are very easy to perform and preventing them is a key task for the secure bootloader.
- Power failures and high reliability
According to Murphy’s law “anything that can go wrong will go wrong”. In the case of remote updates installation, the worst point to lose the power or having any kind of hardware glitch that results in a system reset is when the content of the non-volatile memory is altered during the installation of firmware updates. If a power cut occurs in the middle of a FLASH sector copy operation, the state of the destination sector is unpredictable upon the next boot.
A mechanism that can prevent this situation, like the one implemented in wolfBoot, consists in keeping always two copies of the same sector, and using a mechanism based on flags to confirm that each step has been completed. Upon reboot, the operation can be resumed from the last successful operation, so there is no risk of leaving the system in an unrecoverable state.
- Secure boot and secure update transfers
Downloading the new version is a task for the embedded application, or a thread running on top of a real-time operating system. As indicated by SUIT, including the responsibility of transferring the firmware image in the bootloader code
would result in a bigger, more complex secure bootloader with external dependencies on protocol stack implementations and platform-specific device drivers. Embedded systems may in fact access the network picking from a variety of different connectivity technologies available. Not all of these technologies share the same protocol families or transport mechanisms. Some low power communication protocol such as LPWAN may even have stricter requirements on bandwidth or network availability.
wolfSSL is the embedded SSL/TLS library targeted for embedded systems. Being transport-layer agnostic that can provide secure socket communication on top of all kinds of data transfer technologies and operating system or bare metal applications.
Using the latest standard (TLS 1.3) to secure your connections means that devices can communicate to each other and to the back-end on end-to-end secured channels, using the best cryptography available as standard to date.
Some of the benefits of securing all the data in motion using TLS include of course encryption of all the data transferred between two endpoints, and optionally server-side identification for clients that access data, services or remote firmware updates.
On systems where the entire stack is deployed, including TLS socket communication, transferring the firmware images can be done over the same channel so that the update package can travel the network to the firmware consumer securely.
As TLS may not be an option for a subset of device with a very limited amount of resources available, at least encryption should be considered on such devices. wolfCrypt is a crypto engine targeted for embedded, RTOS and resource constraint environments, which is the core component of wolfSSL, but can as well used as standalone library to access the implementation of the most popular algorithms and cyphers.
- Key management and trust anchors
In a distributed system architecture designed for remote firmware updates, key management is a critical task. The back-end system is in charge of keeping the private key (or keys) safe, and generating signed packages to distribute to firmware consumers when a new version is available.
wolfBoot is distributed with a toolbox of key management scripts and utilities that can be easily integrated on server side to facilitate these tasks. In the simplest case, the signature that is included in update packages is obtained using a private key which is accessible by the owner of the device. In some cases, a more elaborated key provisioning system is in place. When a separate software or hardware component is performing the signature step, the package creation process can be split to redirect and delegate the DSA step to another component.
The public key that is stored inside the embedded system is considered a ‘trust anchor’, because the trust in the validity of the remote firmware updates depends on the integrity of the public key used for digital authentication.
Trust anchor management is in general outside the generic scope of a bootloader itself because it depends on the hardware platform. However, it is of primary importance to include adequate protections against the risk of compromising the public key stored on the device and used by the bootloader to validate the authenticity of the firmware. A trust anchor store should be protected against write access using the available countermeasures available in hardware.
- Secure elements and trust anchor stores
The best way of protecting trust anchors and other cryptographic material is using a hardware component that is designed for this purpose. Hardware security module (HSM, CAAM, etc.) usually offer both key storage and cryptographic operation acceleration in the same module. wolfCrypt, our crypto engine that powers wolfBoot, supports all possible schemes from a wide range of manufacturer-specific API to access this functionality, such as Microchip ATECC608A, ARM CryptoCell, NXP CAU/mmCAU/LTC, STMicroelectronic PKA, Infineon-Cypress PSoC6 and many others. Find the exhaustive list of hardware crypto we support here.
More recently, an effort of agreeing on the protocols used to the access to security cryptoprocessors, ISO/IEC standardized the TPM (Trusted Platform Module) format, which is in use nowadays in nearly all personal computers and notebooks. The same technology is now available for embedded systems thanks to wolfTPM, a library providing APIs to access TPM 2.0 compatible secure element. Popular TPM devices supported by wolfTPM include the ST33 and the Infineon 9670.
wolfBoot can as well be optionally compiled together with wolfTPM to make use of secure key storage and cryptography acceleration provided by these devices. It also support measured boot, storing the firmware hash into a TPM Platform Configuration Register(PCR).
- Updating the bootloader
The SUIT proposed standard recommends that the small bootloader is immutable, due to the intrinsic complexity for the bootloader to implement a reliable way to update itself. However in some cases it is useful to have the possibility to update the bootloader code itself.
Consider for example a situation where the public key is built-in the bootloader code, key provisioning relies on a single private key and this key gets compromised on the back-end.
Another case is a long life product, where the algorithms or the key length in use by the bootloader code today may become obsolete, or compromised, by many years of research. In a few years it may become a requirement to update the bootloader code to match new requirements.
For these reasons we think that giving the possibility to update the bootloader code is important. wolfBoot can be optionally compiled to support this option. A special update package that is marked as wolfboot self-update will cause the bootloader to overwrite its own code after a successful validation of the package itself.
The bootloader update process is not completely fail-safe due to intrinsic hardware constraints, but it is sufficiently reliable to be used for those emergency cases described above.
- Estimating the development effort
When approaching secure boot and remote updates, it is often too easy to underestimate the impact of this single task on the development cycle of the entire project. A large amount of effort is spent on guaranteeing the reliability of the system in all the possible cases that could occur when the device is deployed.
The bootloader is perhaps the most critical part of the system. Everything else in your application can break, as long as there is still a way to update it from a remote location. Implementing a secure bootloader from scratch for a specific project is a tough task which in some cases may require as much development and testing as all the rest of the software components in the system.
At wolfSSL we have several years of experience in supporting our customers to build secure boot and remote updates solutions, and we have designed wolfBoot to provide a solid platform that can be used as the fundamental building block that can fit any secure boot architectural requirements.
We are available to talk with you about your design and we are happy to provide design and development services to complete the integration with any custom embedded system.
We understand how important security is in your IoT project, and we are the only company to offer 24×7 support on secure boot solutions for remote firmware updates.
Contact us at firstname.lastname@example.org with any SSL/TLS, crypto, or secure boot questions!
The New Year release of wolfMQTT, v1.11.0, is now available! This release has several bug fixes and optimizations including:
- Return correct error code in SN_Client_Connect (PR #268)
- Removing unsupported TLS and SNI options in sn-client (PR #266)
- Fixes for multithreading with non-blocking (PR #252)
- Doxygen work removing depreciated command and fixing other warnings (PR #264)
- Fix overwriting TLS error in connect (PR #259)
- Add GitHub Actions (PR #256 #260 #263)
- Fix wm_Sem on Windows (PR #255 #261)
- Fix scripts for host without mosquitto (PR #257 #265)
- Trim whitespace and convert tab to spaces (PR #251)
- Refactor of write length (PR #250)
- Fixes for publish edge cases (PR #248)
- Remove unused sub_id element, add support for local test broker (PR #249)
- Fix to make sure MqttClient_DecodePacket called in all cases (PR #246)
- Known bug with multithread and without nonblocking enabled in this release.
Check out the changelog from the download for a full list of features and fixes, or contact us at email@example.com with any questions:
While you’re there, show us some love and give the wolfMQTT project a Star!
You can download the latest release here: https://www.wolfssl.com/download/
Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT
Are you a user of the ARM CryptoCell acceleration hardware? If so, you will be happy to know that wolfSSL has support for CryptoCell with wolfCrypt and benchmark examples to the wolfSSL embedded SSL/TLS library!
The wolfSSL port supports the following features:
- AES CBC
- Elliptic Curve Digital Signature Algorithm (ECDSA) – sign and verify
- Elliptic Curve Diffie Hellman (ECDH) – shared secret
- ECC key generation support
- RSA sign and verify
- RSA key generation support
- RSA encrypt and decrypt
These features are tested on nRF52840 hardware platform with Nordic nRF5_SDK_15.2.0.
You can use the WOLFSSL_CRYPTOCELL macro to activate the CryptoCell support in wolfSSL. For instructions on how to build and run the examples on your projects, please see the “<wolfssl-root>/IDE/CRYPTOCELL/README” file. This support is currently located in our GitHub master branch, and will roll into the next stable release of wolfSSL.
wolfSSL provides support for the latest and greatest version of the TLS protocol, TLS 1.3! Using the wolfSSL port will allow your device to connect to the internet in one of the most secure ways possible.
For more information, please contact firstname.lastname@example.org.
The most recent version of wolfSSL can be downloaded from our download page, here: https://www.wolfssl.com/download/
wolfSSL GitHub repository: https://github.com/wolfssl/wolfssl.git
wolfSSL support for TLS 1.3: https://www.wolfssl.com/docs/tls13/
wolfSSL is holding an upcoming webinar on January 20th, 2022! Join wolfSSL engineer Eric Blankenhorn to learn more about our wolfMQTT library, built to be multi-platform, space conscious and extensible. The wolfMQTT library is a client implementation of the MQTT written in C for embedded use, and supports SSL/TLS via the wolfSSL library. Bring your questions for the Q&A session to follow!
When: Jan 20, 2022 10:00 AM Pacific Time (US and Canada)
Topic: Getting Started with wolfMQTT
Register in advance for this webinar:
After registering, you will receive a confirmation email containing information about joining the webinar. We look forward to seeing you there!
Questions? Please contact us at email@example.com.
Here at wolfSSL, we like to be on the cutting edge of things. Sometimes that means supporting algorithms before they are widely adopted which can lead to supporting algorithms that do not get wide adoption. This has been the case for the following algorithms:
To reduce code complexity, we have decided to deprecate support for these algorithms. Sometime in a future release, these algorithms will no longer be present in wolfSSL. If this poses a problem for you or your customers, please get in contact with your sales representative or email us at firstname.lastname@example.org as soon as possible.
Here at wolfSSL we are at the cutting edge of cryptography and protocols. For example, even before TLS 1.3 was fully standardized, we were implementing it in line with the draft RFCs. Also, with the progress that is being made in the quantum computing space, we are keeping abreast of post-quantum cryptography and the standardization process for post-quantum algorithms. If you want, you can even experiment with the new algorithms by configuring wolfSSL using `–with-liboqs`.
We would like all our customers to know that we are also aware of and actively watching the standardization process of cTLS. It has the following features:
– Omitting unnecessary values that are a holdover from previous versions of TLS.
– Omitting handshake messages and field required for backwards-compatibility with earlier TLS versions.
– More compact encodings.
– A template-based specialization mechanism that allows pre-populating information at both endpoints without the need for negotiation.
– Alternative cryptographic techniques, such as semi-static Diffie-Hellman.
The protocol specification claims to ensure security by mapping the data from the wire protocol back to a full TLS 1.3 transcript with the same features used.
If you are interested in cTLS then please let us know by sending a message to email@example.com so you can be the first to know when we have completed the implementation of this feature!
wolfSSL will be attending CES 2022! This onsite conference takes place in Las Vegas on January 5–7 from 9:00AM – 5:00PM PST. Join us at the exhibition to connect with wolfSSL Business Directors Stephen Siderewicz and Paul Dennison, who are ready to answer all your embedded security questions!
For location details, guidelines, and more information, visit www.ces.tech.
Join us for our upcoming webinar on January 5th, 2022! This webinar will provide attendees with the basics and best practices needed to get started using the wolfSSL TLS library in products and projects into 2022. Topics will include a brief overview of TLS 1.3, wolfSSL package structure, how to build wolfSSL, running the wolfCrypt cryptography test and benchmark applications, wolfSSL basic API usage, tips on debugging, and more. Bring your questions for the Q&A session to follow!
When: Jan 5, 2022 10:00 AM Pacific Time (US and Canada)
Topic: How to Get Started with wolfSSL in 2022
Register in advance for this webinar:
After registering, you will receive a confirmation email containing information about joining the webinar. We look forward to seeing you there!
Questions? Please contact us at firstname.lastname@example.org.
We’re pleased to announce that we’ve added support for SNI and TLSx options for CMake builds in wolfSSL v5.0.0! Server Name Indication (SNI) is useful when a server hosts multiple “virtual” servers at a single underlying network address. It may be desirable for clients to provide the name of the server which it is contacting.
For more details, visit our blog post on using SNI with TLS here: https://www.wolfssl.com/ssl-termination-and-ssl-inspection-with-wolfssl-sni/
More information on building wolfSSL and configuring options can be found in the wolfSSL manual.
WolfSSL v5.0.0 includes an added build option to configure wolfSSL with the alternate certificate chain feature enabled! Default wolfSSL behavior is to require validation of all presented peer certificates. This also allows loading intermediate Certificate Authorities (CA’s) as trusted and ignoring no signer failures for CA’s up the chain to root. Enabling alternate certificate chain mode only requires that the peer certificate validate to a trusted CA.
The newly added build improvement allows the option
--enable-altcertchains to be appended to the
./configure script to build the wolfSSL library with alternate certificate chain mode enabled.
More information on building wolfSSL can be found in the wolfSSL manual.
- January 2022 (9)
- December 2021 (13)
- November 2021 (29)
- October 2021 (15)
- September 2021 (15)
- August 2021 (13)
- July 2021 (21)
- June 2021 (19)
- May 2021 (12)
- April 2021 (12)
- March 2021 (27)
- February 2021 (29)
- January 2021 (22)
- December 2020 (21)
- November 2020 (14)
- October 2020 (7)
- September 2020 (22)
- August 2020 (11)
- July 2020 (8)
- June 2020 (14)
- May 2020 (15)
- April 2020 (14)
- March 2020 (4)
- February 2020 (24)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (24)
- August 2019 (21)
- July 2019 (8)
- June 2019 (13)
- May 2019 (35)
- April 2019 (31)
- March 2019 (20)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (10)
- October 2018 (18)
- September 2018 (18)
- August 2018 (8)
- July 2018 (15)
- June 2018 (29)
- May 2018 (15)
- April 2018 (11)
- March 2018 (19)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (7)
- September 2017 (8)
- August 2017 (6)
- July 2017 (11)
- June 2017 (8)
- May 2017 (10)
- April 2017 (5)
- March 2017 (7)
- February 2017 (1)
- January 2017 (8)
- December 2016 (3)
- November 2016 (2)
- October 2016 (18)
- September 2016 (8)
- August 2016 (5)
- July 2016 (4)
- June 2016 (10)
- May 2016 (4)
- April 2016 (5)
- March 2016 (4)
- February 2016 (12)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (6)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (13)
- January 2015 (6)
- December 2014 (7)
- November 2014 (3)
- October 2014 (2)
- September 2014 (11)
- August 2014 (6)
- July 2014 (9)
- June 2014 (11)
- May 2014 (11)
- April 2014 (9)
- March 2014 (3)
- February 2014 (3)
- January 2014 (5)
- December 2013 (9)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (8)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (9)
- December 2012 (13)
- November 2012 (5)
- October 2012 (7)
- September 2012 (4)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (5)
- April 2012 (7)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (6)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (8)
- May 2011 (12)
- April 2011 (4)
- March 2011 (12)
- February 2011 (8)
- January 2011 (13)
- December 2010 (17)
- November 2010 (12)
- October 2010 (14)
- September 2010 (11)
- August 2010 (20)
- July 2010 (14)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)