RECENT BLOG NEWS
Live Webinar: Medical Device Security
Learn a comprehensive overview of the current medical device landscape, the associated security challenges, and how wolfSSL’s solutions can help you navigate these complexities effectively.
Check it out: Medical Device Security: Key Strategies for Cyber Security and Data Protection
In the rapidly evolving medical device sector, ensuring the security and integrity of devices is paramount. Join our expert, Eric Blankenhorn, as he delves into the intricacies of the medical device landscape, exploring common attack vectors, regulatory requirements, and emerging security trends. Discover how wolfSSL’s suite of solutions can safeguard your devices and ensure compliance with industry standards.
Key topics that will be covered include:
- Overview and Trends: Introduction to wolfSSL and the latest security trends in medical devices.
- Regulatory Compliance: Learn about regulatory requirements and how wolfSSL meets them.
- Solutions and Use Cases: Discover wolfSSL’s solutions and real-world use cases in the medical sector.
- Key Technologies: Overview of wolfSSL’s SSL/TLS, wolfCrypt FIPS 140-2/3, and wolfBoot.
- Advanced Features: Explore wolfSentry and wolfSSL robust testing protocols.
Don’t miss out on this opportunity to elevate the security of your medical devices. Watch it now and take a proactive step towards safeguarding your devices against emerging threats.
As always, our webinars include Q&A sessions. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
Changes to Maximum Alternative Names Macro in wolfSSL
In the 5.7.2 release, a new macro WOLFSSL_MAX_ALT_NAMES was introduced to limit the maximum number of allowed subject alternative names to a default value of 128 to prevent a possible denial of service attack. Unfortunately, after the release, some commonly used certificates were brought to our attention that have more than 128 subject alternative names. If you started using 5.7.2 and hit error -161 on certificate handling this may be your problem. This issue can be immediately mitigated by building with WOLFSSL_MAX_ALT_NAMES at a number larger, say 512 or 1024. The wolfSSL master branch already has an increased default of 1024 which should be sufficient for all real world certificates and will be included in the 5.7.3 release.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
FIPS 140-3 and SHA-1 Retirement
In December 2022, NIST announced that the venerable SHA-1 algorithm, introduced in 1995, is at end-of-life. While wolfSSL does not use or recommend SHA-1 for new designs, we implement and support it in our products. With the NIST announcement, that will soon change for new FIPS 140 submissions, as we too will retire SHA-1.
The wolfCrypt module holds the world’s first SP800-140Br1 FIPS 140-3 validated certificate #4718 includes SHA-1. Thus, customers with an existing requirement for SHA-1 will be able to satisfy that requirement with wolfCrypt FIPS 140-3.
However, and regardless of FIPS status, customers still using SHA-1 in security-critical roles — signatures, authentications, HMAC, KDFs, etc. — should refactor the implicated systems to use a modern hash algorithm such as SHA-2 or SHA-3. wolfSSL stands ready to help our customers select and implement an appropriate migration path.
All FIPS 140 modules submitted on or after December 31 2025 will exclude SHA-1, to avoid early certificate sunset under the timeline announced by NIST.
In preparation for this transition, wolfSSL has already prepared its FIPS 140-3 codebase to build, run, and pass full ACVP testing, with SHA-1 gated out. We are also routinely testing our mainline and FIPS codebases to assure correct function with SHA-1 disabled.
For more information on the announcement from NIST, check here.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
wolfProvider Release 1.0.0
wolfSSL is proud to announce the release of wolfProvider 1.0.0. This release is the first official support for being a Provider for OpenSSL 3.x. Intended for use by customers who want to have a FIPS validated module, but are already invested in using OpenSSL. The provider gives drop-in replacements for the cryptographic algorithms used by OpenSSL. The wolfProvider uses the wolfCrypt engine underneath which is FIPS 140-3 certified.
Refer to the README.md found in the release for usage instructions. We also maintain a ChangeLog.md for a list of changes in each release.
If you have questions about any of the above, please contact us at facts@wolfssl.com or +1 425 245 8247.
Download wolfSSL Now
wolfSSL secures the world’s first SP800-140Br1 compliant FIPS 140-3 Validation Certificate
In case you missed the news, wolfSSL Inc., a globally renowned leader in cryptography and network security solutions, is thrilled to announce the world’s first SP800 140Br1 compliant FIPS 140-3 Validation Certificate #4718 for wolfSSL’s wolfCrypt module.
EDMONDS, Wash., July 16, 2024 /PRNewswire-PRWeb/ — wolfSSL, INC., has partnered with AEGISOLVE, INC., on this unprecedented automated pilot program. Aegisolve is accredited by the National Voluntary Laboratory Accreditation Program (NVLAP Lab Code: 200802-0) for Cryptographic and Security Testing to assess and validate cryptographic based security systems and telecommunications infrastructure.
“As we move forward, wolfSSL remains focused on enhancing our technologies and expanding our capabilities. We are dedicated to continuous innovation in security. The advancements in our FIPS 140-3 module highlight our commitment to delivering state-of-the-art cryptographic solutions that meet the rigorous demands of today’s cybersecurity landscape.” Stated wolfSSL’s CTO, Todd Ouska. “Our collaboration with AEGISOLVE is just the beginning of a new era in cryptographic security, paving the way for future innovations and industry standards.”
“As a first of its kind, this is a tremendous achievement and a huge step forward for the next generation of FIPS 140-3 Validated Cryptographic Modules.” Reported Travis Spann, Founder and President of AEGISOLVE (NVLAP Lab Code: 200802-0). “AEGISOLVE is proud to have collaborated with the high-caliber wolfSSL team in the NIST SP800-140Br1 Pilot Project to achieve this groundbreaking milestone and we are eager to assist others to achieve the same goal.”
FIPS 140-3 validation testing is a rigorous and extensive process including detailed source code reviews, design reviews, documentation reviews, finite state machine verifications, CVE threat analysis, error injection, port sniffing, configuration management verifications, operational testing and test evidence auditing to the applicable requirements of the FIPS 140-3 Derived Test Requirements and FIPS 140-3 Implementation Guidance.
The National Institute of Standards and Technology (NIST) under the Cryptographic Module Validation Program (CMVP) issues the 140 Publication Series to coordinate the requirements and standards for cryptographic modules for use by departments and agencies of the United States federal government.
Highlights: Under wolfCrypt FIPS 140-2, power on times in standard and embedded targets could be slower due to power on self test requirements of the module. With the wolfCrypt FIPS 140-3 module self-tests are now only required the first time an algorithm is used or when the application decides is an ideal time to run the test during a slower event cycle and ahead of first algorithm use. This means much faster boot times and optimal power and resource consumption with careful planning!**
Differences between wolfCrypt FIPS 140-2 and wolfCrypt FIPS 140-3:
– 3DES removed from the module, 3DES no longer available
+ CAST (conditional algo self tests)
+ KDF-TLS, TLS v1.2 KDF and TLSv1.3 KDF
+ SSH KDF
+ AES-OFB mode
+ RSA 3072, 4096 and PSS
+ New Degraded mode of operation, which means that in the event of a CAST failure other algorithm services will remain available.
* FIPS 140-3: Federal Information Processing Standard Publication 140-3. For more about what FIPS is please checkout these blogs:
- What is FIPS (long version)
- What is FIPS (short version)
- Everything You Need To Know About FIPS 140-3
** For information on transitioning from 140-2 to 140-3 please checkout our blog: What is the difference between FIPS 140-2 and FIPS 140-3?
If you have questions about any of the above, please contact us at fips@wolfssl.com or +1 425 245 8247.
Download wolfSSL Now
wolfSSH 1.4.18 Now Available!
It is Christmas in July! The summer release of wolfSSH is here, version 1.4.18!
Version 1.4.18 brings with it bug fixes, new features, and some enhancements as well! New features in this release include new algorithms and a memory configuration option.
We also have a nice round of enhancements which range from channel setup callbacks, better testing, improved portability, and more!
New Features
- wolfSSL style static memory pool allocation support.
- Ed25519 public key support.
- Banner option for wolfSSHd configuration.
- Non-blocking socket support to the example SCP client.
Improvements
- Documentation updates.
- Update the Zephyr test action.
- Add a no-filesystem build to the Zephyr port.
- Update the macOS test action.
- Refactor certificate processing. Only verify certificates when a signature is present.
- Update the Kyber test action.
- Refactor the Curve25519 Key Agreement support.
- Update the STM32Cube Pack.
- Increase the memory that Zephyr uses for a heap for testing.
- Add a macro wrapper to replace the ReadDir function.
- Add callback hook for keying completion.
- Add function to return strings for the names of algorithms.
- Add asynchronous server side user authentication.
- Add ssh-rsa (SHA-1) to the default user auth algorithm list when sha1-soft-disable is disabled.
- Update Espressif examples using Managed Components.
- Add SCP test case.
- Refactor RSA sign and verify.
- Refresh the example echoserver with updates from wolfSSHd.
- Add callback hooks for most channel messages including open, close, success, fail, and requests.
- Reduce the number of memory allocations SCP makes.
- Improve wolfSSHd’s behavior on closing a connection. It closes channels and waits for the peer to close the channels.
Fixes
- Refactor wolfSSHd service support for Windows to fix PowerShell Write-Progress.
- Fix partial success case with public key user authentication.
- Fix the build guards with respect to cannedKeyAlgoNames.
- Error if unable to open the local file when doing a SCP send.
- Fix some IPv6 related build issues.
- Add better checks for SCP error returns for closed channels.
- In the example SCP client, move the public key check context after the WOLFSSH object is created.
- Fix error reporting for wolfSSH_SFTP_STAT.
- In the example SCP client, fix error code checking on shutdown.
- Change return from wolfSSH_shutdown() to WS_CHANNEL_CLOSED.
- Fix SFTP symlink handling.
- Fix variable initialization warnings for Zephyr builds.
- Fix wolfSSHd case of non-console output handles.
- Fix testsuite for single threaded builds. Add single threaded test action.
- Fix wolfSSHd shutting down on fcntl() failure.
- Fix wolfSSHd on Windows handling virtual terminal sequences using exec commands.
- Fix possible null dereference when matching MAC algos during key exchange.
Visit our download page to download the release bundle, or clone it from GitHub. Feel free to email us at facts@wolfssl.com or support@wolfssl.com or call us at +1 425 245 8247 with any questions about the wolfSSH embedded SSH library or other products.
Download wolfSSL Now
Live Webinar: Secure and Reliable Firmware Updates with wolfBoot
Learn the intricacies of connected embedded systems and the challenges they face, particularly focusing on the pivotal role of secure boot mechanisms in enhancing security.
Watch it today for “Secure and Reliable Firmware Updates with wolfBoot.”
In today’s interconnected world, the ability to remotely update various artifacts within embedded systems is crucial. However, this convenience brings about significant security risks that must be meticulously addressed. Join our expert, Daniele, as he provides an in-depth guide on securing embedded systems, highlighting the importance of secure boot mechanisms and introducing wolfBoot as a premier solution in firmware security.
Key topics that will be covered include:
- Explore IoT security challenges impacting device integrity and data protection.
- Learn how a secure bootloader ensures trusted firmware updates.
- Discover wolfBoot’s capabilities in secure firmware updates and device reliability.
- Understand the importance of trust anchors for system integrity.
- Dive into cryptographic algorithms for firmware authentication and update management.
- Learn about new wolfBoot features enhancing security and functionality.
Don’t miss out on this chance to fortify your knowledge and skills in securing embedded systems. Check it out today and take a step towards securing your IoT devices against emerging threats.
As always, our webinars include Q&A sessions. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
Everything You Need To Know About FIPS 140-3
wolfSSL is currently the leader in embedded FIPS certificates. With current FIPS 140-3 validated certificate #4718 for the wolfCrypt Cryptographic Module, wolfSSL is thrilled to hold the world’s first SP800-140Br1-compliant FIPS 140-3 Validation Certificate. Join the wolfSSL team as we cover all things FIPS 140-3. We will cover the current transition to FIPS 140-3, its importance for cybersecurity, as well as how wolfSSL is implementing it in our products.
Watch the video: Everything You Need to Know about FIPS 140-3
FIPS 140-3 is the third revision of the Federal Information Processing Standard (FIPS) for cryptographic modules. The new revision of the standard includes an increased focus on algorithm agility, updated requirements for testing and validation, including changes to the testing methodology. wolfSSL is at the forefront of this important transition, and is working to ensure that its products continue to meet the highest standards of security and compliance.
FIPS 140-3 establishes the security requirements for cryptographic modules used by the U.S. government, as well as other organizations in the public and private sectors. By complying with the FIPS 140-3 standard, organizations can have greater confidence in the security of their cryptographic solutions, which is particularly important in today’s world where data breaches and cyber attacks are becoming more frequent and sophisticated.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
What is FIPS (short version)
Doing FIPS responsibly since 2014!
FIPS is a set of standards, detailed in Special Publications, that need to be met to be awarded a FIPS validation/certification published on the NIST website.
A FIPS certificate, with the product listed in the certificate, is required to sell product(s) to medical, federal, or military agencies and is often required by some private sector entities as well.
The typical FIPS certification process is as follows:
- You send us your hardware and toolchain
- We run the initial tests which ensure the cryptography module behaves according to specification given your specific hardware and OS
- The CMVP certified lab runs and verifies the tests and their documentation
- The test results are submitted to NIST for review
- Your specific operating environment is added to our certificate
- You are FIPS 140 compliant in 60-90 days
For more info please see the long version of this post.
If you have any questions about FIPS or the process of being awarded a FIPS validation/certifcation please contact us at fips@wolfssl.com, support@wolfssl.com or +1 425 245 8247 anytime. We offer free pre-sales customer support, we have FIPS evaluation options and our staff are knowledgeable and eager to help!
Download wolfSSL Now
What is FIPS (long version)
Doing FIPS responsibly since 2014!
INTRO (wolfSSL FIPS service(s)):
(skip to next paragraph for “What is FIPS”)
FIPS is rightly viewed as a complex process with a steep entry learning curve. Lucky for customers of wolfSSL Inc. our management and engineering team have taken the time to learn the documentation surrounding the topic and developed all the tooling necessary to complete FIPS validation testing of the wolfCrypt cryptographic module in coordination with an NVLAP accredited FIPS lab. In order to FIPS validate a new product or operating environment (OE), wolfSSL asks for simply a customer’s hardware, compiler/toolchain (IDE etc), and a guide such that one of our FIPS developers can sit down with nothing but a laptop and achieve compiling and running a hello-world.c application on the target product to be FIPS validated. Yes you read that right, wolfSSL does not need your proprietary application software, just a hello-world.c application to get started. The CMVP validates the cryptographic module running on the target, not the applications that are consuming that cryptographic module. The wolfSSL team will standup the wolfCrypt module on your target product and take it through the certification process as quickly as possible leaving your dev team free to focus on preparing the end product while FIPS certification is taking place simultaneously!
HISTORY (What is FIPS):
Since there are so many options for securing information, the U.S. and Canadian governments recognized in the 1990’s a need to standardize those algorithmic methods deemed to be the most secure and enforce use of only those algorithms in critical government systems. To “encourage” adoption of the requirements by the two governments, the organizations NIST (National Institute of Standards and Technology)¹ and the CCCS (Canadian Centre for Cyber Security)² were called upon to fulfill that mission. The two agencies were to collaboratively:
- Decide which algorithms were the best/strongest
- Evaluate: If an algorithm had multiple modes or key lengths which modes or key lengths (if any) were considered too weak and should be excluded?
- Determine if there were other requirements aside from just having the algorithms implemented correctly
- Did the algorithms NEED to be re-tested periodically? (IE as the device was powering up)
- Did the module need to be checked periodically to see if it had been tampered with since the factory? (IE an integrity check, etc)
- Finally to enforce/encourage adoption of these standards by federal agencies belonging to either government. (Eventually expanded to include medical and some private entities as well)
These standards were called the “Federal Information Processing Standards” or FIPS. These standards were documented in a series of “Special Publications” (SP’s).
Out of a need to document which cryptographic modules and vendors were abiding by the standards set forth, a “certification” program was decided as the best approach. Vendors who made cryptographic modules could submit for and be awarded a certificate if their module was found to be compliant with all standards applicable to that module. The certificates would be hosted on the U.S. based NIST website so that federal agencies (or the public) could “browse” the available FIPS certified modules.
It was a big job for the two agencies to handle alone, so in 1995 NIST and CCCS established two organizations called the “CMVP” (Cryptographic Module Validation Program)³ and CAVP (Cryptographic Algorithm Validation Program)? to handle testing Cryptographic modules for compliance with the standards. These two organizations would also handle issuing the certificates for vendors and products that passed algorithm testing and were found to meet all applicable standards outlined in the SP’s.
The CAVP issues algorithm certificates (which are a prerequisite to submitting a module for FIPS certification to the CMVP). The CMVP issues FIPS certificates for “tested configurations” or “operating environments” found to pass the CAVP testing and be in compliance with the standards. Both certificate types (CAVP algo certs and CMVP FIPS certs) are hosted on the NIST website. The certificates are public domain and can be searched by anyone.
Once established, the CMVP and CAVP needed to establish a way to “test” the modules. To that end they called upon the NVLAP (National Voluntary Laboratory Accreditation Program)? to accredit “third-party” testing laboratories that would serve as an intermediary between the vendors seeking FIPS certification and the CAVP/CMVP bodies.
A last step in the history of FIPS was adoption of software modules. Originally when the standards were written, only dedicated hardware could perform the heavy lifting necessary for cryptographic mathematical operations so the standards were designed with ONLY hardware modules in mind. Doing cryptography in software at the time was impractical and therefore not considered in the original standards. As general purpose CPUs advanced, eventually it became feasible to implement algorithms in software and have those expensive math operations executed by a general purpose CPU in a reasonable amount of time. Once this reality arrived the standards were “adapted” to allow for both hardware and software modules. To this day there are “some scenarios” in the standards that only seem to make sense for hardware (See our blog post on vendor affirmation and how some software vendors are exploiting a loophole in the standards that was intended for hardware). NIST, the CMVP and CAVP have done a lot of work in the past few years bringing about the latest 140-3 standards and wolfSSL Inc is very excited to be one of the first software modules with a commercial FIPS 140-3 offering!
The Process (validating a module):
Today a hardware or software vendor will work in coordination with an NVLAP accredited lab to complete algorithm testing and receive algorithms certificates.
(Milestone 1 of a FIPS certification effort)
Once the vendor receives the prerequisite CAVP certificates they will perform operational testing with the same NVLAP accredited lab. Once all testing evidence has been captured and everything reviewed and approved by the NVLAP quality assurance department, the lab is ready to submit everything to the CMVP.
(Milestone 2 of a FIPS certification effort)
The CMVP will coordinate with the vendor via the NVLAP accredited lab and once all requirements have been satisfied the CMVP will either issue a new FIPS certificate or update an existing certificate if the vendor is adding an operating environment to an existing certificate.
(Milestone 3 of a FIPS certification effort)
Submission Scenario(s) supported by wolfSSL Inc:
- New cert (draw a new module boundary around specific algorithms and certify from scratch resulting in a new certificate)
- OE addition (Add an OE to an existing certificate)
- Revalidation (redraw the module boundary of an existing validated module to include new or remove existing algorithms from the boundary description)
- Vendor Affirmation – wolfSSL is a software module vendor. As a responsible FIPS vendor wolfSSL feels that software vendors are generally incapable of determining how a change to the CPU or OS will affect the cryptography (especially if the CPU or OS changes completely). As such wolfSSL Inc does not currently offer Vendor Affirmation as a path to FIPS. Special circumstances MAY exist but would need to be evaluated on a case-by-case basis.
Timeline estimates for the various scenarios change over time. If you would like an up-to-date estimate for a given submission scenario please contact support@wolfssl.com for the latest.
Summary:
- wolfSSL Inc can make the process of certifying your product painless and hands-free once we have the product and basic instructions for getting a hello-world app up and running on the target!
- FIPS is a set of standards, detailed in Special Publications, that need to be met in order to be awarded a FIPS validation/certification published on the NIST website. A FIPS certificate, with the product listed in the certificate, is required to sell product(s) to medical, federal or military agencies and often required by some private sector entities as well.
- The process can take time so please plan accordingly!
If you have any other questions about FIPS or the process or wolfSSL Inc please contact either fips@wolfssl.com or support@wolfssl.com anytime. We offer free pre-sales customer support, we have FIPS evaluation options and our staff are knowledgeable and eager to help!
¹ The National Institute of Standards and Technology (NIST) was founded in 1901 and is now part of the U.S. Department of Commerce. NIST is one of the nation’s oldest physical science laboratories. To promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life. – https://www.nist.gov/about-nist
² The Cyber Centre is the single unified source of expert advice, guidance, services and support on cyber security for government, critical infrastructure owners and operations, the private sector and the Canadian public. – https://www.cyber.gc.ca/en/about-cyber-centre
³ The Cryptographic Module Validation Program (CMVP) is a joint effort between the National Institute of Standards and Technology under the Department of Commerce and the Canadian Centre for Cyber Security, a branch of the Communications Security Establishment. The goal of the CMVP is to promote the use of validated cryptographic modules and provide Federal agencies with a security metric to use in procuring equipment containing validated cryptographic modules. – https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program
? The CAVP was established in July 1995 by NIST and the Government of Canada’s CCCS. CSD’s Security Testing, Validation, and Measurement Group (STVMG) manages the validation testing of cryptographic modules and their underlying cryptographic algorithms through the CAVP and CMVP. – https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program
? The National Voluntary Laboratory Accreditation Program (NVLAP) provides third-party accreditation to testing and calibration laboratories in response to legislative actions or requests from government agencies or private-sector organizations. NVLAP-accredited laboratories are assessed against the management and technical requirements published in the International Standard, ISO/IEC 17025:2017. – https://www.nist.gov/nvlap
If you have questions about any of the above, please contact us at facts@wolfssl.com or +1 425 245 8247.
Download wolfSSL Now
Weekly updates
Archives
- December 2024 (15)
- November 2024 (29)
- October 2024 (18)
- September 2024 (21)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- 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)